[Oberon] minor tuning of TUI?

[Richard Hable]

Am 2016-06-10 um 14:54 schrieb eas lab:

[...]
> 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.

Yes, that's a real problem. Back when I was using the Oberon System, I
repeatedly fell into the trap of either closing the last viewer of a
document with unsaved changes or overwriting changes due to separately
opened viewers from the same file.

> 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.

I tried to find a solution for that, but came to no satisfying solution:
once a viewer has been opened based on a file's content, it is
independent from this file. The user may or may not save the document by
clicking on the store command, he may change its name in the menu and
then store, and possibly overwrite a different document, etc.

There is no one-to-one relationship between documents stored in files
and documents shown in one or more viewers. Therefore, we can't really
scan the tree of open viewers and find out what belongs together.

I think, in order to solve the problem it would be necessary to have an
additional layer between files and viewers: something which handles a
list of open documents, with references to files and viewers. All the
editors would have to be changed to use this layer to open, store,
rename etc. documents.

Of course, this is not possible without creating a completely different
version/distribution of the Oberon System. IMO this shows that, while
the Oberon System is rightfully called an "extensible system"--you can
easily create new, extended versions of tools like editors and
compilers--, it is not an "adaptable system", because you can not change
the behavior of the base modules.

Richard