[Oberon] ETHO work flow tools.

[Bob Walkden]

> "Knowledge" OTOH, is heirarchically/tree-like structured

Actually, it's relational.

> it's inevitable that a
> critical one will be Grown to cover others.  Once that is done, choas
> will set in, since inconsistent copies of 'papers under the pile' will
> be created..

are you sure about this? Texts operate on the MVC principle, so if you have
multiple views open on the same model then any change to the model should be
broadcast to the views which should respond by refreshing themselves from
the model.

B

> -----Original Message-----
> From: eas lab [mailto:lab.eas at gmail.com]
> Sent: 09 January 2013 08:47
> To: oberon at lists.inf.ethz.ch
> Subject: [Oberon] ETHO work flow tools.
> 
> It's quiet likely that others have discovered this little quirk,
> without mentioning it: a serious flaw in the work-flow model of ETHO.
> 
> Analysing why A2 doesn't work for me, led to recognising a similar flaw
> in ETHO.
> 
> My ancestors wrote on the cave walls. Later in Babylon they wrote on
> slate & clay-tables. And then they had the mess of a zillion papers and
> chaos. Like me.
> Until a saviour arrived and suggested that:
>  make all papers the same size [compatible];  number/ID and pysically
> order them meaningfully;  bind them together [with a hinge];  add a
> table-of-contents, to a unique, heuristically chosen location;
>    and we'll call it a "BOOK".
> 
> Novels have a linear structure, and could be contained in a scroll,
> because they don't need RAM. "Knowledge" OTOH, is heirarchically/tree-
> like structured, and needs RAM; which a "book" achieves.
> ===========
> 
> ETHO S3 largely achieves the superior discipline/constraints of a book;
> whereas A2 is the same mess as Microsoft Windows.
> 
> Although I did some substantial software projects in the Turbo Pascal
> [and before that] days, I can't cope with ETHO. But now I've found out
> why.
> 
> As the complexity of the project expands:.
> the number of textFrames opened increases and it's inevitable that a
> critical one will be Grown to cover others.  Once that is done, choas
> will set in, since inconsistent copies of 'papers under the pile' will
> be created..
> 
> IIRC TurboPascal [for DOS] showed only one textFrame at a time, but
> there was a stack-menu of recent textFrames, which prevented the
> described problem.
> 
> Interestingly, `wily` [the public domain version of Plan9's acme] which
> acknowledges being based on ETHO, seems to have anticipated and handled
> the described problem. Eg. if you've got testFrames A,B,C & you <Grow>
> A to cover B & C, and then later <reload> B, then the previous <Grow>
> of A is reversed so that the already loaded B is visible. I.e. the
> *existing* B pops out.
> ==
> Apparently ETHO has anticipated the problem too, and gives the solution
> of a
> <popupmenu>: but IIRC it caters for only *.Mod, *.Tool files, which
> restiction seems bad. Perhaps a 'separate-class' can be created for
> other file-name extensions. BTW, a serious problem with LEO is the
> hiding of the filename, due to the field length overflow by long path-
> names. `mc` handles this well by showing the rightmost/most-relevant
> text. How does A2 for Win & Linux handle this problem of showing long
> pathnames in a restricted width field?
> ==
> Rather than the technical details being  the limiting factor, it's the
> human work-flow aspects that are important in computing.
> Apparently one can be working away for years, without seeing the bigger
> picture.
> "Just get on with the job" is a disasterous short-term attitude.
> ==
> Doutlessly the BIGGEST picture is keep-it-simple, ie. limit the number
> of chunks that the user has to keep in mind at one time..
> A menu condenses N items into one. A book disciplines N pages into one.
> ..
> == Chris Glur.
> ..
> PS. I've just been looking at a LEO file <TextPopups.Tool> which may
> have come from ETHO, or been partially created by me, which seems to
> handle many of the problems raised above.
> Apparently this fix was introduced late in the evolution of ETHO.
> How did the Turbo Pascal designer manage to solve the problem 20 years
> earlier?
> 
> --
> Oberon at lists.inf.ethz.ch mailing list for ETH Oberon and related
> systems https://lists.inf.ethz.ch/mailman/listinfo/oberon