[Oberon] minor tuning of TUI?

[eas lab]

I'm trying to re-find the URL of the very competent 'human-
computer-interface' designer, which was [I believe]  *.ch ?

Reports have shown why users don't appreciate ETHO and
acme/sam/wily.

ETHO would be easily tuneable to remove some objections.
The first has already been done by acme/sam/wily [plan 9's
copy of ETHO].

If you've got 4 TextFrames open and you want to do some
complex operation on one of then, then you'd Grow that
one to full UserFrame size; and likely 'branch-off' on some
task which might need a Frame which is now covered, or
you may need some as yet unOpened Frame.

After completing that complex operation you SHOULD have
forgotten that you covered 3 Frames. If you DO remember that,
you shouldn't be using a computer, since you aren't working at
the limit of your memory!

wily, of which I normally have more instances running than
LinuxETHO, solves the problem: it moves the hidden Frame
to the foreground, when the Frame is 'called'.

ETHO can give bad results, if you hadn't saved the hidden Frame-A
before you "just temporarily?" Grew Frame-E to full Track;
and then made changes to the newly re-fetched old Frame-A.

Can't ETHO just scan the Frame tree, before loading a Frame
from file, and if the Frame is already open, then move it to
foreground.    wily also puts the cursor to the just loaded Frame.

Although we lose the ability to get both the filed version and the
loded/open but not yet Stored version, a new command could
exist to handle this rare requirement.

Critics, emphasise the time needed to move the hand between
keybrd and mouse. Since the most common need for such
movement, is after a text section is typed, and it is saved.

Would it be difficult to have a hot-key [I favor F2] to:
<Store the Frame which received the latest keybrd input>?

== Chris Glur.

PS. wily has problems too.