August 2002 - Oberon - mailman3.inf.ethz.ch

Re: [Oberon] Re: New Oberon users bootstrap improvement project
by muller＠inf.ethz.ch 25 Aug '02

25 Aug '02

Stefan Salewski <Salewski(a)physnet.uni-hamburg.de> wrote: > I think that there is enough documentation and information > to install ETH-Native-Oberon or BlueBottle-Oberon and start using it. I also think so, but perhaps its organization could be improved to "steer" complete newbies better. Of course, many people (myself included) read as little documentation as possible. > At each new installation my biggest problem is again and again the > danger of destroying the integrity of the other two > operating-systems, which resides on my computer, and which I need for > my daily work. Unfortunately there is no way to guarantee that one operating system won't corrupt the data of another operating system except by physically separating and removing the storage devices. An example is that Windows 2000 will corrupt Native Oberon 2.3.6 partitions, since it incorrectly "recognizes" them as FAT partitions and tries to "fix" them. Ironically, afterwards Windows 2000 itself will crash when it scans the "fixed" partition. (This problem was solved in later Native Oberon releases by specially disguising the partitions from Windows 2000). Also, it is not inherently safer to install Native Oberon to a FAT partition instead of repartitioning the disk. It is only more convenient. In fact, the FAT solution is more complicated and therefore more likely to contain errors. > But this is only true for people who are willig to invest some time > and effords. If we want to increase the number of Oberon-Users > outside of ETH, than more good documentsation, accessible without a > running Oberon-System, is necessary. Many people prefer to print out > complete installation instructions before starting installation. That was the aim with André Fischer's text: http://www.oberon.ethz.ch/installA.txt (it will be updated for the new release). For users who can easily find their way around a new system, there is the "documentation path" I described in an earlier mail. As an aside: I believe one should try to use the Oberon system itself as much as possible from the beginning. That is the idea behind the Oberon-0 system used for installation. Of course this is more complicated than the "Dummies" approach of a graphical Windows-based installation program run from CD, but it is also more flexible, e.g. it is possible to install a usable Oberon programming environment on old hardware using a single installation diskette. Both approaches have their advantages. Bluebottle also uses the "Oberon-0 approach" for installation, with the important difference that the boot diskette is replaced by a boot CD, which contains the complete system. Therefore it can either be used as-is (without installation), or it can be used to install itself on a hard disk. -- Pieter -- Pieter Muller, Computer Systems Institute, ETH Zurich / MCT Lab, Zurich Native Oberon OS: http://www.oberon.ethz.ch/native/

1 0

Native Oberon alpha updated
by muller＠inf.ethz.ch 25 Aug '02

25 Aug '02

An updated Native Oberon alpha version is now available at: ftp://ftp.inf.ethz.ch/pub/ETHOberon/Native/Update/Alpha/ The detailed changes are listed at: http://www.oberon.ethz.ch/native/WebAlpha.html All changes up to 24.08.02 are in the downloadable version. Notably, the Oberon-0 installation diskette now supports FAT-based installation again, using the completely rewritten FAT file system (from the Dummies release) of Bernhard Egger. Important things remaining to do for the planned beta release: o apply remaining updates (NetSystem, Mail, etc.) o improve installation workflow and documentation o bring on-line installation documentation in line with new concepts http://www.oberon.ethz.ch/installA.txt o improve release build tools to make it easier for others to use Afterwards we'll start a round of testing and error documentation and correction, aiming for a release by the end of the year. -- Pieter -- Pieter Muller, Computer Systems Institute, ETH Zurich / MCT Lab, Zurich Native Oberon OS: http://www.oberon.ethz.ch/native/

1 0

(no subject)
by Frank van Riet 25 Aug '02

25 Aug '02

Most of the traffic on the mailing list is devoted to the OS aspects of Oberon. I'd like to digress from this for a while and get some feedback on the language itself. First of whatever I say is only aimed at Oberon 1 and 2 i.e not Active Oberon, although some of it may be applicable. I have used Oberon in developing commercial software for some time. I'd like to know if anyone else has been doing the same. I have the following comments on some limitations that I have experienced. Some of my comments are specific only to the ETH implementation of Oberon while others are fundamental to the language. Please note that this is not an attack on the language, I'm asking :) Oberon per se: 1) The lack of unsigned data types is a great annoyance. Sure there are ways of getting around this, but I cannot see that Oberon has gained anything as a language by not supporting unsigned types. Sure it makes the compiler simpler, but not significantly. Perhaps it is because of the potential complexities of mixing signed and unsigned types in expressions ? This also does not seem like a convincing argument. It could simple have been disallowed. 2) In developing large systems for different platforms, conditional definintions are a real life saver. (e.g. (Borland?) Pascal's $IFDEF) I'm not sure if this is a language or an implementational issue, although I suspect it is the former. Apart from having code for differing platforms. Conditionals will get rid of the clutter of debugging code CONST debug = TRUE; ;;; IF debug THEN .... which is painfully inefficient. The below is perhaps more related to the ETH implemetation. Others may very implement these differently. 3) Dynamic array headers: Why was the decision made to to stick the header in the middle of the structure and not in-front as with other structures. Not only is it non-intuitive nit having the pointer point to the firts element, but it would also make language interoperability very difficult. Let alone the nightmare of porting older code in which this was not the case... 4) Pragmas are only allowed on a per module basis. It would be very usefull to disable type guard checking in many cases, simply for the sake of efficiency. True it compromises security, but why allow it at all then. As an aside does anyone know whether read-only exports are still supported ? Frank --------------------------------------- Frank van Riet (Software Developer) Datavoice (Pty) Ltd Snail mail PO Box 582 Stellenbosch 7599 South Africa Tel +27 21 888-2118 Mobile +27 82 970 5704 Web http://www.datavoice.co.za ----------------------------------------

3 2

Tracing Oberon-0 boot problems
by muller＠inf.ethz.ch 24 Aug '02

24 Aug '02

Doug Danforth <danforth(a)greenwoodfarm.com> is having problems getting any version of Native Oberon to work on his machine. We are now systematically trying to trace the problem. Since this might be of interest to others, and others may want to contribute with their experiences, I'm taking the discussion to the mailing list. To recap, Doug said (speaking of the Oberon-0 boot diskette): > Under both V2.3.6 and Alpha no cursor appears on my screen. (I believe under > some other version of Native I had a red cursor which now I can not reproduce). And I asked: That probably means booting did not work out. We should concentrate on finding out why. What exactly do you see after booting the Alpha version of Oberon-0? If you don't have a visible cursor, what do you see in the System.Log? Do the Oberon tracks even appear, or is the screen just black? To which he replied: > Yes, the tracks do appear. The system track is as expected and the > user track is all grey. There simply is no cursor and the keyboard > does not seem to do anything. And now we are "live" again with this email... (BTW we've decided to concentrate on the Alpha version). These are startup commands in Oberon-0 (from Install.Oberon.Text in Alpha/Build/Build.zip), one of them is apparently hanging: { System.OpenLog } { System.Open Install.Tool } { UsbSystem.Start } { UsbMouse.Init } { UsbKeyboard.Init } { ConfigInput.WatchMouse 3 } { Config.Oberon0 on } My guess would be one of the Usb commands, since the first two commands have apparently been executed (you see the log and Install.Tool in the system track), and the last two are quite harmless. When it is hanging, do the NumLock/CapsLock keys toggle the corresponding LEDs? If not, keyboard interrupts are probably not working. If the LEDs work, try Ctrl-Break (once or twice) and let us know what the resulting trap viewer says. This should show us which command above is hanging. > Yes, I used the same diskette. I can not reproduce the results of > Partitions.Show for 2.3.6 because it now traps (which is what it has > always done except for that one time). Ok, let's ignore 2.3.6. > > > Warning: Logical drive chain points to sector without partition table. > > > > This is potentially a problem, but we need more information from > > Oberon itself. If you answer the questions above we can proceed. > > Ok (see above) > So why should I have a working ME system that does not complain and > yet partinfo doesn't like it? The primary partition table format is quite old (DOS 2.0?) and the extended partition table format also (DOS 3.0?). These formats were never very well documented by Microsoft (especially in earlier years), so a lot of the information about them is based on folklore collected over the years. Therefore different programs often make different assumptions about what the tables should look like. This is especially a problem with the extended partition table and logical drives, which have a relatively tricky nested linked list structure. partinfo is probably being conservative, and ME not. > I have *not* > systematically tried every combination. I have tried explicitly setting PS2=1 > and also MouseType=0 thru 6 but to no avail. With the Alpha version it is not really necessary to configure the mouse beforehand using OBL config strings. Paul Reed modified the post-2.3.6 Input module to detect the mouse automatically and this is successful in most cases. The "ConfigInput.WatchMouse 3" command in the Oberon-0 startup is a fall-back for the rare case where the autodetection fails. It installs a task that "watches" the mouse cursor for 3 seconds. If any movement is detected, the task prints "Mouse movement detected" and terminates. If not, it prints "Press Shift to configure mouse" and when the SHIFT key is pressed, it calls the ConfigMouse.SelectMouse command, which allows manual cycling through the mouse drivers and ports with the keyboard. To conclude, once we have the answer to the questions about the keyboard LEDs and Ctrl-Break above, we can continue. -- Pieter -- Pieter Muller, Computer Systems Institute, ETH Zurich / MCT Lab, Zurich Native Oberon OS: http://www.oberon.ethz.ch/native/

2 6

the threat that Oberon could improve?
by Charles Angelich 24 Aug '02

24 Aug '02

>Message: 7 >From: cglur(a)onwe.co.za >To: oberon(a)inf.ethz.ch >Cc: cglur(a)onwe.co.za >Date: Sat, 24 Aug 2002 07:14:57 +0200 (SAST) >Subject: [Oberon] Displays and fonts and RX >Reply-To: oberon(a)inf.ethz.ch > > >> >Since 07.02.01, System.Directory on Native Oberon supports >> >additional flags. This is currently only documented in >> >http://www.oberon.ethz.ch/native/WebAlpha.html, excerpt below: > >OK. System.Directory *.Tool\fd ~ gives what Charles want { use F1 }; >except IMPORTANTLY it should be date ordered. Reversed is best. >So, further refinements for the next version ? No, actually this does NOT do "what Charles wants" and it was YOU who said you had a need for a listing you could sort by date. How did this become MY need? I've repeatedly reminded everyone here that the Native/Alpha was never finished and will NOT install into one large FAT file? Does no one read anymore or is long term memory at a premium? The default file format was changed, the commands to use this file format were renamed, it was never intended that a person like myself could finish this and use it. In fact, as I remember this you cannot even type into that user track and I have no idea why? >Charles Angelich wrote: >> Not including documentation within Oberon installs seems to be >> a reocurring theme. > >Well yes, that's life. It's inevitable for documentation to lag with >non-commercial products. Pity. Lag? Yes, I would say close to two years without documentation is a bit of a LAG! You sarcasm is noted also. You need to re-adjust your persona a notch. >> I also added a dot within the ZERO char to assist in reading >> Oberon source code when the capital "O" is being used along with >> the "0" (zero) char. Not pretty really but easier on the eyes IMO. > >Then you're aware of the many existing fonts, and that you can choose >the size and boldness you want. Also easily design your own chars. with >Desktops.OpenDoc FontEditor.Panel ~ I see three fonts useable for English language text? This is what you call MANY? I know people with 700 fonts installed on their machines. >Since you're interested in 'appearance' perhaps you can be our >resident artist ? You made a request for a sortable, by date, directory display then you ridicule what I have to say about it and now you think I'm your "boy"? Think again. >Did you look at: FontEditor.Panel -> Shanghai.Scn.Fnt >eg. chars 20Hex, "3", "4" ? Amazing stuff. >Is your alpha 2001 FontEditor.Panel also 'eratic' when 'keying' ? >A 'senior' n-o user on c.l.o. tells me that my problems are imaginary. I don't have Alpha installed here because it will not install. Write this down because by tomorrow you will have no memory of this text whatsoever. Yes, I noticed the bugs in the font editor. It also reverts back to previous filenames if you "grow" a font display over the top of it then "close" the font display. Cute bug since you then save the font overwriting a different font and eventually lose all your other fonts. Neat huh? >> btw: What happened to the Syntax#.Scn.Fnt I find in W31. I like >> that font! > >I don't know/use W31-oberon, but # is not a valid char for a filename. The Syntax#.Scn.Fnt is mentioned as the "fall-back" when the requested font is not found re:Oberon documentation. You apparently don't RTFM a great deal either. The "#" is a place-holder representing a number. All font names also have a number remember? >> If using a proportional font as the default for Native Oberon is >> the crutch to justify the inability to do clean standard displays >> then I would submit that a default proportional font was a mistake. > >I (and apparently others) like the feel of Oberon10.Scn.Fnt . >When I get a table or an ascii-art-schematic which needs fixed-width >font, I just 'wipe-it' and 'dab' my Courier8.Scn.Fnt text-bit which >is on my personalTool/pallette. You, and apparently others, don't do a great deal with numbers and therefore have no need of columnar displays. Odd because the favorite contributed app seems to always be some form of number cruncher. I guess when you're doing cute graphs and charts you don't care about displaying the data for verificiation of accuracy? >Not easy for 2-button/dumbed-down use. The only "dumb" here is that people think they're elite with a 3 button mouse. The cost is $7 US new here in Michigan. Get over it. >Paul Reed wrote: >> It strikes me that taking a system like Native Oberon >> and trying to make it usable on 640x480 is like trying >> to make a motorbike by sawing a car in half. > >I wonder why I never felt the pain and deprivation ? You have nothing to use Oberon for other than a screen saver? >When I first intalled V2.3.2 I just selected the default (VGA) and was >completely satisfied. Same for V 2.3.6. And when I installed Linux based, >the virtual screen was bigger than the physical, so it slides around when >the cursor hits the edge - most annoying. I'm guessing X-setup would fix >that, but life is too short. I found the extra area of the linux version >usefull for cramped jobs, like font editing with FontEditor.Panel . Yes, Oberon does have nice screen savers if you like the old-style graphics. >When I started using alpha 2001, I couldn't understand how they would >design the Desktops.OpenDoc's store button to be inaccesable unless Grown >to full screen size ( which crashes .html fetched texts -- which nobody >would admit for 1 year !!). Now you understand this? >I strongly beleive in 'information hiding', and considered experimenting >with different VDU settings as opening a can of worms, until Charle's >complaints drew my attention to the possibility. "Information hiding" is like calling rust "iron oxide". Rust is rust and mistakes are mistakes by any name you can think of. >The fact that the default Oberon10.Scn.Fnt gives you about 79 chars in >the UserTrack with 640x480, also suggests it's OK. What am I missing ? You are missing the shared experience of having 100's or even 1000's of Oberon users writing the code, fixing what needs to be fixed, and sharing their experiences with you. Given the option to have these experiences you would rather be sarcastic and fight to maintain the status quo which is totally contrary to all the folklore about Wirth and what he tried to do during his career. Wirth, as described, would not smile at what you are fighting for here. 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

1 0

documentation, installation instructions
by Charles Angelich 24 Aug '02

24 Aug '02

>Message: 6 >Date: Fri, 23 Aug 2002 21:26:57 -0400 >From: "Douglas G. Danforth" <danforth(a)greenwoodfarm.com> >Organization: Greenwood Farm Technologies LLC >To: oberon(a)inf.ethz.ch >Subject: [Oberon] Bluebottle documentation >Reply-To: oberon(a)inf.ethz.ch > >Andre, Patrik, Pieter, Folks, > >Issue: Bluebottle documentation and the "background of obviousness". > >I look at the process of moving now to installing Bluebottle and >blanch (turn white). Why? Many of the terms are unfamiliar to >me. I would not expect this (some but not so much) after nearly >40 years of programming. Welcome to the pit of despair. :-) >In hopes of improving the Bluebottle installation process I will >go through the online documentation with annotated >comments which are meant to be helpful and suggestive of change. > >The phrase "What is not said is purposefully left unsaid" (paraphrase of >Dr. Wirth) is fine, but only up to a point. For introduction to >new areas verboseness is better than tersness. However, it takes >a great deal of work to make writing simple and concise. It is easy >just to through in the kitchen sink. > >Let's start with "http://bluebottle.ethz.ch/index.html" >o "SMP-compatible" I deduce from context but is undefined. >The rest of the page is fairly clear. > >Jump to "http://bluebottle.ethz.ch/instreq.html" (Requirements) >I have a great deal of difficulty with this page, not so much in >the specifics but "what is left unsaid". Namely, where is the >overview saying "you need a great deal of hardware knowledge >to install Bluebottle". Where is the statement that you can >severly damage or destroy your current system if you are not >very careful? Idenitical to the situation for Native/Oberon where the options to trash your existing system are at the top and only if you take the time to read to the bottom do you find you can install into one large FAT file and avoid the risks. :-\ >I believe that Bluebottle attracts users to the website first and >that Native Oberon is a secondary interest to the newcomer so that >assuming they know about Native is not a good idea. There are assumptions that users know how to use DOS and THAT is not always true anymore. Obviously they used SOMETHING to download Oberon to their hardware. What that something IS is a mystery apparently? Within the documenation a user is told that they can use Oberon's FTP to download ARC files before they even get to the point of configuring Oberon to be able to connect to their ISP. >"Partition" needs to be extensively defined with examples given >so that the user knows what they are getting into. Good luck on this one. ;-) >"If you have a boot manager, logical drives in extended partions may also >work (e.g., with LILO, BootMagic, NT BootLoader)" > >What's a "logical drive"? What's an "extended partition". What is >a boot manager? Why is it that the "may" work? Good point. Another interesting assumption that they "mystery OS" used to download Oberon has all of these capabilities. >"LILO" needs to have Linux associated with it. >"BootMagic" needs to be removed and replaced with "PartitionMagic" >since BootMagic is no longer supported. Probably should be rewritten to use LOADLIN.EXE? >"The latest version of the ZipTool is also required to unpack the zip files. " >But now that I have a Native partition that has no access to the internet >how do I get "any" file from the web into the Native file space? >Copy to floppy and then execute ...??... what command from Native? Until a recent "fix" I suspect the ZipTool might not have actually worked anyhow? >"Disk space: In addition to an existing Native Oberon installation, one free partition of about 100MB for Bluebottle. If you >want to boot Bluebottle, the partition has to be a primary partition on the first 8GB of the hard disk." > >When I did Partitions.Show I was shown what partions already existed on >my drives. Nowhere in the installation process was I given the option >of "repartioning" my drives. If this is possible in one of the steps >then *here* in the Bluebottle documentation it should say "If you don't >have a boot manager then from within the Native installation you can >repartion at step ... of the installation process" These are SOME of the reasons I have argued in favor of a plain text file of installation instructions with system requirements, system setup requirements, and possibly the names of available software to get for arranging to do all of this? Obviously all but the Linux versions of Oberon rely on a working knowledge of DOS and it's utility applications but no one likes to admit to relying on lowly old DOS even though the need is obvious. > >More later. I will be looking forward to observing your progress. I wish you all the luck in the world - you will need it. ;-) 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

1 0

American humor
by Charles Angelich 24 Aug '02

24 Aug '02

>Message: 3 >Date: Fri, 23 Aug 2002 18:00:28 +0200 >From: Josef Sedlacek <sedlacek(a)swissonline.ch> >To: oberon(a)inf.ethz.ch >Subject: Re: [Oberon] Narrow Displays and Oberon Language >Reply-To: oberon(a)inf.ethz.ch > >Dear Paul > >Excellent. This combination of good argumentation with the dry english humor. > >Thank you very much for motorbike and swimming. I had to laugh as much as I did >not for a long time. I have some American humor for you to laugh at. Will you be laughing when there are only two or three Oberon users remaining because new users were told to buy hardware they could not afford or go elsewhere? 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

1 0

How to discourage new Oberon users
by Charles Angelich 24 Aug '02

24 Aug '02

>Message: 1 >Date: Fri, 23 Aug 2002 14:15:32 +0100 >From: Paul Reed <paulreed(a)paddedcell.com> >To: oberon(a)inf.ethz.ch >Subject: [Oberon] Narrow Displays and Oberon Language >Reply-To: oberon(a)inf.ethz.ch > >> From: GitM >> > The OS is not ONLY about exercising the hardware. It is also about >> > communication with the USER. > >> From: "Thomas Frey" <frey(a)inf.ethz.ch> >> Therefore the original Ceres workstation had a 1024x800 display >> resolution > >Thomas, I totally agree with you. As I've said, I >have a Ceres 3 on my desk and its monitor is a modified >Moniterm VCX1000 manufactured in Minnetonka, MN, in the >US of A way back in March 1990. I'm trying to start at the FOUNDATIONS that ETH Obern established with the release of Native/Beta. I am not trying to impress you or any other person on this elist What you haven't noticed is that I do have an installed Native/Beta on another machine with the 1024x768 display. I have 5 computers with Oberon installed on two of them. I have ETH Oberon Native/Beta, ETH W31 Oberon 3, Linz Oberon V4 all installed here in front of me. I also have access to an 800mhz with a 19" screen and I've never even bothered to find out what it's maximum display capabilities are as yet. Now tell me one more time about your wonderful monitor. >My guess is that the >monitors cost ETH more than each Ceres, anyone from >ETH in that era care to comment? :) Ask me if anyone really cares about Ceres hardware? >The point is, it's a 21" screen, and Oberon's beautifully >crisp and clear at 1024x768 (viewable area 17"). No, it's not "crisp and clear". It's useable like most any other GUI interface would be. It could be better if anyone really cared at all in any way to make it better. >The first time I got the same experience with other >hardware that I could afford was last year, when I bought >a Sony VAIO with a really nice 1024x768 TFT display (tape >measure again: 14" viewable area). Notice the word "afford"? Do you not care what others can afford? Are you an elist bourgeoise who thinks the peasants should fend for themselves? Are college students wealthy now and can buy anything dictated to them by the software required by the courses they chose to enroll in? Microsoft thinks this way and everyone hates them for it. >I think this demonstrates how far Wirth and Gutknecht >were ahead of their time, and so it is understandable >that they didn't feel the need to pander to the conventions >being tentatively established on how GUIs should work - >it was far from a foregone conclusion! > >As has widely been observed, departing the "bandwagon >trail" allowed them to simplify greatly the way the >whole system worked. For some people, it's too simple >(like not having columns, or overloading the mouse >instead of having to remember keyboard shortcuts). You are attempting to evangelize two men who built a system for their personal use. Anyone building a single user system would customize it to their own personal habits. This wasn't a crusade it was just how people are. Human nature. >But although I have made great efforts to adapt >Oberon to legacy hardware (e.g. narrower displays), I >view these adaptations as "specialist applications" >and I wouldn't expect the maintainers of ETH Oberon to >be particularly worried about them (I hope you're >reading this Pieter :]). Yes, as long as it works on YOUR hardware it should remain as it is. A great philosophy if you want there to be only a few dozen Oberon users. >I sympathise with people's desires to make Oberon >run on diverse hardware (because I do it myself) but >it is impossible to do this without cutting at the >very heart of the design principles which make >Oberon great. An inability to do columns with the default font is not "great" it is absurd. Lack of word-wrap is not "great" it is an oversight. Menu bars that disappear offscreen look like a hack-job. >It strikes me that taking a system like Native Oberon >and trying to make it usable on 640x480 is like trying >to make a motorbike by sawing a car in half. It srikes me as elitism and arrogance to say that. 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

1 0

How to discourage new Oberon users
by Charles Angelich 24 Aug '02

24 Aug '02

>Message: 1 >Date: Fri, 23 Aug 2002 14:15:32 +0100 >From: Paul Reed <paulreed(a)paddedcell.com> >To: oberon(a)inf.ethz.ch >Subject: [Oberon] Narrow Displays and Oberon Language >Reply-To: oberon(a)inf.ethz.ch > >> From: GitM >> > The OS is not ONLY about exercising the hardware. It is also about >> > communication with the USER. > >> From: "Thomas Frey" <frey(a)inf.ethz.ch> >> Therefore the original Ceres workstation had a 1024x800 display >> resolution > >Thomas, I totally agree with you. As I've said, I >have a Ceres 3 on my desk and its monitor is a modified >Moniterm VCX1000 manufactured in Minnetonka, MN, in the >US of A way back in March 1990. I'm trying to start at the FOUNDATIONS that ETH Obern established with the release of Native/Beta. I am not trying to impress you or any other person on this elist What you haven't noticed is that I do have an installed Native/Beta on another machine with the 1024x768 display. I have 5 computers with Oberon installed on two of them. I have ETH Oberon Native/Beta, ETH W31 Oberon 3, Linz Oberon V4 all installed here in front of me. I also have access to an 800mhz with a 19" screen and I've never even bothered to find out what it's maximum display capabilities are as yet. Now tell me one more time about your wonderful monitor. >My guess is that the >monitors cost ETH more than each Ceres, anyone from >ETH in that era care to comment? :) Ask me if anyone really cares about Ceres hardware? >The point is, it's a 21" screen, and Oberon's beautifully >crisp and clear at 1024x768 (viewable area 17"). No, it's not "crisp and clear". It's useable like most any other GUI interface would be. It could be better if anyone really cared at all in any way to make it better. >The first time I got the same experience with other >hardware that I could afford was last year, when I bought >a Sony VAIO with a really nice 1024x768 TFT display (tape >measure again: 14" viewable area). Notice the word "afford"? Do you not care what others can afford? Are you an elist bourgeoise who thinks the peasants should fend for themselves? Are college students wealthy now and can buy anything dictated to them by the software required by the courses they chose to enroll in? Microsoft thinks this way and everyone hates them for it. >I think this demonstrates how far Wirth and Gutknecht >were ahead of their time, and so it is understandable >that they didn't feel the need to pander to the conventions >being tentatively established on how GUIs should work - >it was far from a foregone conclusion! > >As has widely been observed, departing the "bandwagon >trail" allowed them to simplify greatly the way the >whole system worked. For some people, it's too simple >(like not having columns, or overloading the mouse >instead of having to remember keyboard shortcuts). You are attempting to evangelize two men who built a system for their personal use. Anyone building a single user system would customize it to their own personal habits. This wasn't a crusade it was just how people are. Human nature. >But although I have made great efforts to adapt >Oberon to legacy hardware (e.g. narrower displays), I >view these adaptations as "specialist applications" >and I wouldn't expect the maintainers of ETH Oberon to >be particularly worried about them (I hope you're >reading this Pieter :]). Yes, as long as it works on YOUR hardware it should remain as it is. A great philosophy if you want there to be only a few dozen Oberon users. >I sympathise with people's desires to make Oberon >run on diverse hardware (because I do it myself) but >it is impossible to do this without cutting at the >very heart of the design principles which make >Oberon great. An inability to do columns with the default font is not "great" it is absurd. Lack of word-wrap is not "great" it is an oversight. Menu bars that disappear offscreen look like a hack-job. >It strikes me that taking a system like Native Oberon >and trying to make it usable on 640x480 is like trying >to make a motorbike by sawing a car in half. It srikes me as elitism and arrogance to say that. 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

1 0

Displays and fonts and RX
by cglur＠onwe.co.za 24 Aug '02

24 Aug '02

> >Since 07.02.01, System.Directory on Native Oberon supports > >additional flags. This is currently only documented in > >http://www.oberon.ethz.ch/native/WebAlpha.html, excerpt below: OK. System.Directory *.Tool\fd ~ gives what Charles want { use F1 }; except IMPORTANTLY it should be date ordered. Reversed is best. So, further refinements for the next version ? Charles Angelich wrote: > Not including documentation within Oberon installs seems to be > a reocurring theme. Well yes, that's life. It's inevitable for documentation to lag with non-commercial products. Pity. > I also added a dot within the ZERO char to assist in reading > Oberon source code when the capital "O" is being used along with > the "0" (zero) char. Not pretty really but easier on the eyes IMO. Then you're aware of the many existing fonts, and that you can choose the size and boldness you want. Also easily design your own chars. with Desktops.OpenDoc FontEditor.Panel ~ Since you're interested in 'appearance' perhaps you can be our resident artist ? Did you look at: FontEditor.Panel -> Shanghai.Scn.Fnt eg. chars 20Hex, "3", "4" ? Amazing stuff. Is your alpha 2001 FontEditor.Panel also 'eratic' when 'keying' ? A 'senior' n-o user on c.l.o. tells me that my problems are imaginary. > btw: What happened to the Syntax#.Scn.Fnt I find in W31. I like > that font! I don't know/use W31-oberon, but # is not a valid char for a filename. > If using a proportional font as the default for Native Oberon is > the crutch to justify the inability to do clean standard displays > then I would submit that a default proportional font was a mistake. I (and apparently others) like the feel of Oberon10.Scn.Fnt . When I get a table or an ascii-art-schematic which needs fixed-width font, I just 'wipe-it' and 'dab' my Courier8.Scn.Fnt text-bit which is on my personalTool/pallette. Not easy for 2-button/dumbed-down use. Paul Reed wrote: > It strikes me that taking a system like Native Oberon > and trying to make it usable on 640x480 is like trying > to make a motorbike by sawing a car in half. I wonder why I never felt the pain and deprivation ? When I first intalled V2.3.2 I just selected the default (VGA) and was completely satisfied. Same for V 2.3.6. And when I installed Linux based, the virtual screen was bigger than the physical, so it slides around when the cursor hits the edge - most annoying. I'm guessing X-setup would fix that, but life is too short. I found the extra area of the linux version usefull for cramped jobs, like font editing with FontEditor.Panel . When I started using alpha 2001, I couldn't understand how they would design the Desktops.OpenDoc's store button to be inaccesable unless Grown to full screen size ( which crashes .html fetched texts -- which nobody would admit for 1 year !!). I strongly beleive in 'information hiding', and considered experimenting with different VDU settings as opening a can of worms, until Charle's complaints drew my attention to the possibility. The fact that the default Oberon10.Scn.Fnt gives you about 79 chars in the UserTrack with 640x480, also suggests it's OK. What am I missing ? ca> I don't quite understand your need to combine lines. peter_easthope wrote: > RX.Tool in Oberon does not mention any means of > identifying the beginning of a line. I thought > of 'RX.SetSearch c "Begin" {~c} c'. Logically it > should work for any line except the first but fails > apparently because it spans two lines. > > From my naive viewpoint, the scope for the > matching algorithm should be the entire text. > Anyone with a thorough understanding of how > texts are represented in Oberon can probably read > the RX.Mod files and understand why the scope is > limited. (A nice didactic exercise.) Yes, not being able to work across line boundries is a serious limitation. And also causes it to crash. I wanted to make some 'translations' to help automate converting WordPerfect files (much legal stuff from Inet uses this). And they seems not to have CR and/or LF chars. So RX.Tool is not usable. -- Chris Glur.

1 0