[Oberon] minor tuning of TUI?

[eas lab]

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

OK, wily doesn't allow:
 multiple <same file name> viewers to be different, which facility
  in ETHO can be useful sometimes.

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

Why have you changed my initial terminology from: file & TextFrame to:
 file & viewer & document?
OK, let's use your term Viewer [since Viewer can have multiple TextFrames].

OTOH you have thought more deeply than me on this topic, since I didn't
realise the problem of changing the open-viewer's name.

Am I wrong that, there are:
two entity-types: files & viewers; not 3: files, viewers, documents;
1= files, which may map to viewers which
1.1= match the file;
1.2= do not match the file;
1.3= have no matching viewers

2= Viewers which
2.1= match a file, correspond to 1.1;
2.2= match the name, but not contents of a file, correspond to 1.2;
2.3= have  no matching file-name, but are presumably in the viewer-tree,
       with the name used to open them.

??

Can you put your ideas, in more algorithmic notation?
Maybe even pseudo-code?

== Chris Glur.


On 6/11/16, Richard Hable <informujo at aon.at> wrote:
> 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
>
> --
> Oberon at lists.inf.ethz.ch mailing list for ETH Oberon and related systems
> https://lists.inf.ethz.ch/mailman/listinfo/oberon
>