[Oberon] programming within ETH Oberon now and 2020
Charles Angelich
cangelich at famvid.com
Mon Aug 19 17:45:25 CEST 2002
Hello All -
This is about keeping Oberon viable into the near future as
hardware improves our user display access to the system and
the information maintained within that system. If the user
interface becomes less than comfortable with many addons
dependent on hard-coding the road back will be a trip no one
will be willing to take.
The lack of columnar alignment and possible problems with the
use of the TAB character are basic requirements for a textually
oriented OS. I see no options there.
I would also expect some form of word-wrap when displaying text
files and the addition of code to intercept the file attributes
to increase or decrease the embedded font sizes based on the
available space when using various display sizes. Reset of the
Font.Default is only one-half the solution when going to a
larger display size continues to use the files embeded font size
to display existing source code in miniature sized characters
on a larger display.
It seems that Native/Beta 08.12.00 is hard coded in many
places to assume Oberon10.Scn.Fnt sizes. As video displays
increase in size this will become an increasing weakness of
existing Oberon code. Font.Default should be user selectable
and button sizes, menu bars, and user input textual interface
should ALL calculate sizes based on the Font.Default maximum
letter size. Hard coding saves time and helps keep Oberon
binaries small and fast but it's a problem waiting to interfere
with further developments in the near future.
note: On my 1024x768 display I use a Font.Default of Oberon14.Scn.Fnt.
I don't see Gadgets panels re-sizing for display size which means
at some point THAT user interface will be putting icon sized user
panels on larger display sized screens. If they do resize and I
am mistaken I apologize for my assumptions.
When programming, being able to see a colon ":" as different from
a semi-colon ";" is necessary. The period "." must not be
mistaken for a comma "," nor the letter "O" for the digit zero "0".
Miniature font sizes are not going to promote error free coding.
The "zero" should include a dot or a slash within the character to
differentiate it from the "O" and the number one "1" should not
be kerned all the way to the right having an adverse affect on
the appearance of columnar alignment of digits within Oberon
displays. If the whitespace (empty char) within the font
libraries is, in fact, one-half the size of the letter "A" this
should be corrected within the font libaries (all of them if need
be).
Comments?
Charles Angelich
The Ghost in the Machine!
DOS and W31 Tech website:
http://www.undercoverdesign.com/dosghost
Stories, poems, music, and photos website:
http://www.undercoverdesign.com/dosghost/faf
More information about the Oberon
mailing list