[Oberon] VGA ='offscreen'; n-o paradigm

[cglur at onwe.co.za]

Charles.Angelich  wrote:
> The standard 640x40x4 VGA drive pushes toolbar text offscreen to the
> right on both of my COMPAQ machines.  Even the 800x600 display has
> some text offscreen to the right.

Debugging video drivers is not for a beginner.
I installed Dosbased 2.3.6 to 4 different machines before I had problems
with (apparently) the display.
My (toolbar text ?) Menu Frame at top RHS looks like this:
    System.Log | System.Clear Edit.Locate .Search
DOSbased V2.3.6 should look similar.
OK, yes the text overflows.  That's life.  
Engineering is about making do with limited resources.
If you need (rarely) to access the overflowed command(s), then move the
frame to the LHS, user-track. 

> > The first time n-o starts it gives a default tool, in the RHS 'System Track'.
> > As you progress, you will want to customise this tool for your own liking.
> > I use different colours and fonts (which also serve as my palette to modify
> >   colour and fonts of any text, which I chose to modify).
> 
> What do you access to change fonts and text colors?  That stupid striped
> palette thing seems to do nothing here?
> 
First learn how/what "select" means.

.......... snip .......... 
> Everything you said above is what I understood.  How to tell Search what 
> string to search for is/was my need.  I will try the rightmouse 
> selection - again.
> 
> > obviously for a text string - in fact the most recent 'selected' (RightMs)
> > string.
> 
> For some reason the need/use of rightmouse to select strings got past me
> or wasn't mentioned clearly in the userguide, tutiorial, etc.

N-oberon is based on a few 'very exact' concepts, rather than masses of 
fuzzy stuff.  Science is about reducing/minimising.

 "Select" has a very special meaning with respect to the mouse:
1. Select one character = RM at char
2. Select text range from line start to & including char = double RM at char
3. Select text range spanning several lines = .....
4. Select text range spanning several screens = ...

With n-o if you're remembering much, you're not doing it right.

The repetoire of mouse cords becomes a reflex (like walking).
And you use the simple (minimalist), consistent top structure
(which I fear is degenerating to inconsistency since Prof. Wirth
retired and the pull to ape MS becomes irresistable).

Here's an example:
I want to find the 'tutor' which would explain how to "select" a
text string.
* use the tool appropriate to 'find'.
* since I often need to do this, I've got the appropriate command in my
    personal-tool.  I don't need to remember what it's called.
  I just recognise it as a brown-and-yellow-thing about 80% down the
  command list.  If I want to spend an extra 500mSec to check that the
  brown-and-yellow-thing is the right thing, I read that it's called:
Desktops.OpenDoc   Find.Panel ~
This looks OK.
I know that 'Desktops.OpenDoc' must be activated (MM) and that
'Find.Panel' is it's argument. {The position on the screen is a refinement;
set by [F1] key called "mark" - a central point of the Wirthian approach
is that you master the basics first and refine later}

* the string to look for could be "elect" for "select" or "Select".
   If the file types are still consistent (since Prof. Wirth retired), I would 
    expect the info to be in some *.Text file.

* using this guess I get a list of *.Text files with text stretches around
   my search string: "elect". And visually scanning this list I recognise the
   following line as relevant:
UserGuide.Text	ntiguous piece of text can be selected by moving the mouse

All this takes some 5 seconds and tells me that probably the description of
how to "select" with the mouse is in the file: UserGuide.Text , near the
stuff about: "....ntiguous piece of text can be selected by moving the mouse".
##

This is quiet complicated to verbalise.
But then so is 'taking a foot step' very complicated to verbalise.
Similarly, doing the search is as easy and natural with n-o as doing
the foot step.


Chris Glur.

## There is an 'irregularity' in that UserGuide.Text needs Script.Open
whereas  most *.Text are handled by Edit.Open.
Perhaps renaming the files according to the editor needed would be 
good ?  eg. UserGuide.Script .