<story><title>Oberon OS Walkthrough (2009)</title><url>http://ignorethecode.net/blog/2009/04/22/oberon/</url></story><parent_chain></parent_chain><comment><author>philipswood</author><text>We used Oberon (the system and the language) in our 3rd year CS OS course in Stellenbosch in the mid 90&amp;#x27;s&lt;p&gt;Interesting system, it&amp;#x27;s worth looking at since it has a few unexplored ideas.&lt;p&gt;(I was less impressed the the language).&lt;p&gt;I experienced it at about the same time as win3 &amp;#x2F; Win95 and X-Windows (before KDE&amp;#x2F;Gnome) and it compared favourably.&lt;p&gt;I&amp;#x27;m glad this post is calling attention to it, but I don&amp;#x27;t think the post does it much justice.&lt;p&gt;The Zooming-UI and desktops happened later as a reaction to (today) more mainstream approaches.&lt;p&gt;I wouldn&amp;#x27;t call the interface a CLI - it wasn&amp;#x27;t REPL.
It needed a 3 button mouse and was very point and click.&lt;p&gt;TUI is more accurate.&lt;p&gt;It was graphical, with no desktop and non-overlapping panels (although in certain cases one panel could obscure a lower panel). 
Think tiling window manager.&lt;p&gt;The mouse button use was chorded, so there were a lot of combinations, this meant one could highlight, select, copy, paste and execute commands without using the keyboard.&lt;p&gt;Any text could be selected and executed. Selecting &amp;#x27;Module.Function&amp;#x27; would execute that function in that module.&lt;p&gt;It used a &amp;quot;Document Object Model&amp;quot;, the base text class was expandable to handle more widgets than just native text.&lt;p&gt;Single user, single process with no real distinction between the system code and your own.
You could view and edit system modules and add your own.</text></comment>
<story><title>Oberon OS Walkthrough (2009)</title><url>http://ignorethecode.net/blog/2009/04/22/oberon/</url></story><parent_chain></parent_chain><comment><author>SoSoRoCoCo</author><text>&amp;gt; Everything is a Command Line&lt;p&gt;This is a really controversial pattern for GUIs. In one camp, the GUI is really a skin over the CLI that acts like a virtual user, translating GUI inputs into underlying CLI. In the other camp, the GUI is all there is (e.g., Windows) and there is no underlying OS that can be accessed via CLI: in fact, the CLI is a &amp;quot;fake GUI&amp;quot; (win32 apps written without a Window). I can&amp;#x27;t say which is better, but it is fascinating to see that this was an &amp;quot;original pattern&amp;quot;.</text></comment>