[Oberon] Has BB/Aos got this quirk too?

[Chris Glur]

It's the trivial 'falling in a hole' which eventually makes potential 
new users of ETH-oberon abort, before they have sufficient 
fluency to need to keep using it for the superb text manipulation
facilities.

Has BB/Aos got the following quirk too:-
 you might use a non-gadgets-editors as your default; 
 eg. Edit.Open, ET.Open because it's needed for 
TextMail.Cite, TextMail.Send, News.Send, you don't
want auto-indent ...etc. ?

Then you will often change frames' titles to save as a
'different' file.

This reflex action, of eg. just wiping & pasting a new 
frame-title, doesn't work for gadget-type-frames.

The newly entered frame-title needs to be 'terminated'.
eg. by <F9>.  Some say it's like terminating a command
line with <enter> ?

Another apparent triviality of N-O which is actually
an important principle of HCI, which is part of making 
N-O a winner, is that 'all commands should give a
feed-back-confirmation'.

Therefore normally the failure of the frame's name to
change will be shown in the log during Store.
OTOH if the old/pre-changed-attempt file has no *.Bak,
you may have lost a file by an unintended overwrite  !!

Also when this quirk is combined with eg. learning how to
use the ChangeFontTool, which happens to cover the
log, it's just all too much.

So what do we learn from this:
  this boring triviality is difficult to describe, so it won't
  be mentioned; so potentially new users will fall-in-the
-hole and decide to abort using ETH-oberon.

My money says Aos/BB's advanced technology hasn't
fixed this ?
  
BTW. the need for a pre-emptive OS is mostly needed
to internet access.  Linux-ETH-oberon is a great 
improvement over N-O for inet access.
So what other advantage would I get from Aos/BB ?

What is the size difference between N-O & Aos/BB ?
I had a shock to read that just one of the file of the
Aos-port-to-ARM was over 11MB.
Yes, *.pdf descriptions can be big, and the images are 
not always justified.

Thanks for any info,

== Chris Glur.