[Oberon] Interfaces; was Texts

[eas lab]

You are dealing with a most important part of computing, especially for
Oberon : HumanComputerInterface.

From:   Andreas Pirklbauer <andreas_pirklbauer at yahoo.com>
 Date:   Tue, 1 May 2018 11:25:32 +0200
 > So at least for that task, no more cheat sheet was needed.

}Good!  Ideally a system is self-contained; minimally dependent upon
}external documentation.   How often does a person using a smartphone
} or tablet consult a manual or sticky note?

Not a good example to try to follow: US XmasTree decoration style of
randomly placed Icons. Far better is the decades old proven DropDownMenu
always viewable. Not like this Gmail incompetence, where the user must
scroll to the top or bottom to access the menu.

 > But I havenâęt found a satisfactory solution yet for some of the
 > other operations (e.g., copy-to-caret, copy-looks) other than adopting
 > Ctrl-C/Ctrl-V/Ctrl-X.

} Any implicit or invisible command is problematic.

Yes: always replace "Remembering" with "Recognising", where possible.

}The best  possibility I've imagined is a small floating viewer
}displaying core commands.

The CoreCommands recognises the Tree/Heirarchy/Ontology concept.

}Similar to the popup menu of ET but remaining  open continually.

AFAIR ET's Menu  was needed because the TopBar was fully used?

}Aspect ratio similar to the screen rather than tall and narrow.
}It would track the mouse as the arrow does in extant Oberons.

Wouldn't it be obstructive for a FloatingTextLine to follow
the cursor and cover your working area's view ?

} It would have an arrow point and hotspot somewhere on the perimeter.

? What are these used for?
? So the OneLine floating viewer would be UserTrack wide?

} This "command viewer" would be wide enough for the familiar commands
} "Insert Execute Select" corresponding to the
} three mouse buttons, left, middle, right.

I'm lost in trying to understand.

}A click of a mouse button would activate the corresponding command.

Is this a reversion to the SingleButton klik idea, instead of chording?
Have you seen V4 ? Perhaps some one can send you a visual image?
====== following lines by P.E. not understood :--

The left button would set insertion at the hotspot,
 the middle button would execute the command under the hotspot and
 the right button would select at the hotspot.

 Similar to the existing interface but with implicit commands legible
 in the moving command viewer.

 This command viewer would be scrollable to accomodate arbitrary text.
 The installed form would include core commands and text editing.  On a
 desktop or laptop machine, two mice would allow movement of the
 command  viewer independent of scrolling.  Also achievable with one
 mouse and small complications in protocol.  With a touchscreen,
 movement and scrolling would work more neatly.  The text of the
 command viewer would be editable just as any other text.  Any command
 could be added to the command viewer.  A command in a track viewer
 would execute as in extant Oberons.

 This interface would allow some interesting simplifications. ScrollUp
 and ScrollDown commands could deprecate vertical scroll bars on track
 viewers. The menu bar would need only the name.  Familiar commands
 "System.Close ... Edit.Store" could be in the command viewer rather
 than the menu bar.

 Character insertion and other text editing can also be performed via
 the command viewer.  With the viewer tracking an insertion point,
 characters would be inserted from the command viewer by clicking mouse
 buttons.  Hence the keyboard would be redundant.  (A keyboard would
 continue to work but not be essential.)  Again, two mice would be more
 efficient than one.  A touchscreen even better.

 I can't imagine any simpler way of activating various commands on
 various data with all commands and data visible.  The concepts allow
 integration of a touchscreen interface and the traditional Oberons.
 Nothing really original but combining established features in a new
 way.

 I've implemented a second mouse controlling a left pointer. Not the
 command viewer yet.  The Wikibook has priority for now.
Regards,                                  ... Lyall E.
----------------
PS.
Another problem that didn't exist with N.O. nor DOS8+3, is the
FileName. People who follow the M$ fad of writing a poem instead of
a single Token as the Filename, mess Oberon & wily's MenuBar.

This text was edited by LNO, since coloring was needed to handle the
complexity, and LNO is the only Oberon version that I've managed to run
in 64Bit. Now the S3 text must be transfered to the Gmail's <Frame>.
Consider the absurdity, that if the <sendMail> fails, for any of several
possible reasons, the user who has composed his mesg. in the GmailFrame
has lost all his labour!

== crg