[Oberon] Large displays in Emulated RISC Oberon
lab.eas at gmail.com
Tue Jun 17 05:43:42 CEST 2014
|> That sounds like preferring lose pages to a bound-book?
|It's hard to fax a bound book. ;)
Yes, but ETHO TextFrames can be moved *AND* automagically line-up,
like pages of a book.
I have a very concrete NOW example of the difference between
Displays-which-look-cool and "can it do the vital job":-
In the 90's when the governing authority was handed to the ANC in S.Africa,
understandably the municipal electricity accounts ran-into-chaos.
Because I stupidly didn't realise that the judicial system would also be
overwhelmed by incompetence and chaos, I provoked litigation, in order to
expose in Court, how I was being falsely charged for electricity, for my
rental property, where I had the municipality disconnect the supply.
My rental property was confiscated, and I started accumulation much legal
documentation: obviously using our superior ETHO system.
At that time we used NativeOberon, and I had a separate partition for the
<property confiscated> project. BTW ETHO's coloring facility is useful there.
Since the 90's, the municipal billing chaos has become public knowledge;
with press reports about: riots, arson, murder and several constitutional
cases relating to the billing incompetence/chaos.
So now that it has become obvious that my matter was not about valid account
payment refusal, as it was contrived to be, [Pre-ANC days, such chaos was
unimaginable] I need to dig out my accumulated documentation and research work.
But now we are no longer using NativeOberon, because LEO is better.
Fortunately the old N-O files are conveniently accessible on the same LEO
installation: via LNO.
But my preferred FrameBuffer version of LNO, doesn't show the menuFrame as
<halfShaded>. So if you've got 6 TextFrames on the screen, you can't easily
identify their top-borders; which drastically impedes work progress.
And you only notice the problem, when you do a real serious project.
Now I've noticed that LEO also doesn't show <halfShaded> menuFrames; but
using GadgetFrames, gives the extra-line which identifies the FrameTop.
Every time I change one of the parameters of the <display>: W * H, font,
frameSize ....etc. some other aspect becomes sub-optimal.
There's mention of the <halfShaded> in the source code.
It's complex. Displays are problematic. They initiate many USEnet queries.
== Chris Glur.
More information about the Oberon