The RISC OS GUI
A look at the RISC OS 3.11 graphical interface from Acorn Computers Ltd in the United Kingdom, released in 1992 contemporary with Apple System 7. Please note that I am pretty new to this operating system so there may be inaccuracies and omissions in the text that follows. Many thanks go to David Pilling and Matthew Blissett for their assistance with this article. E&OE.
A few years ago, I gained possession of an Acorn Archimedes 440/1 personal computer, running RISC OS. After failing to understand it without a manual and having negative experiences with stability, I passed the computer on to someone else. However, looking around BeebMaster’s site, I viewed his Archimedes pages. The silly error messages from RISC OS I posted to a Bug of the Moment entry, but it was this photograph that really caught my attention: Econet notification.
It suggests that submenus can be dialog boxes. Spurred on by this, I had a long trawl through Google Images, finding some curious screenshots. I was going to simply appropriate the relevant images for the (now-defunct) Cy/VOS community wiki, but I decided it would be better to install an emulator. This way I could explore the system for myself, find out how it all really works, and take my own screenshots. I present these as a guide to one of the most unusual graphical interfaces around, one that was remarkably advanced compared to other systems of its day and that still has many things to teach those of us designing new graphical interfaces. If we are going to base our work on existing interfaces, why not spice up the mixture with some of the fascinating ideas from the less well-known interfaces such as AmigaOS, RISC OS and Psion’s EIKON.
The RISC OS desktop is divided into two areas: the Pinboard and the Icon Bar. The Icon Bar displays the icons of mounted file systems and related special services (e.g. in-built applications and printers) on the left, and active tasks on the right. The rest of the desktop space belongs to the Pinboard, which can show a backdrop and pinned-up icons. The Pinboard does not represent a folder as with common systems, but allows you to pin up icons of files that exist elsewhere. The pinboard state must be saved to a file in order to be able to be re-opened on next boot.
All icons on the Icon Bar represent active tasks. Each available file system and service is driven by a process that can be easily closed, with Task Manager—the shell, represented by the Acorn logo icon—being the single exception: it is not possible to quit the shell. With all other tasks closed, only the Acorn icon remains:
The Pinboard itself is a process which can be closed, removing the desktop background and icons.
It is of course also possible to overflow the Icon Bar, in which case the contents simply slide across when you hold the cursor over each end:
RISC OS, like the Macintosh, makes extensive use of the mouse to control the system. Unlike the Mac, however, Acorn supplied three-button mice and assigned names and associated functions to all three.
The left mouse button is known as “Select”, and functions the same as left mouse in other graphical interfaces. The middle mouse button is called “Menu” and this button provides access to menus; see the section on menus below.
The right mouse button is called “Adjust” and is rather unusual. It is similar in concept to Apple’s option key – using the Adjust button performs a similar but different action to Select. For example, Adjust-clicking on a scrollbar button or track scrolls in the reverse direction as Select-click. Adjust-dragging a window moves the window without bringing it to the top of the window stack. Using Adjust to open a file or folder closes the Filer window afterwards, similar to holding option on a Macintosh; likewise, Adjust-clicking a Filer window’s close box closes the window and opens its parent. Adjust-click on a file adds or removes a file from the selection, the same as control-click (Windows) or cmd-click (Macintosh). By devoting a whole mouse button to alternative operations, reliance on reaching for the keyboard to find modifier keys is greatly reduced. Moving a file (instead of copying) still requires shift to be held, however.
In general, use of the mouse in RISC OS is much more intelligent than any other graphical interface.
RISC OS does not entertain the debate about in-window menu bars or a global menu bar, as all menus are pop-up menus invoked with the Menu (middle) mouse button. This choice is a strong application of Fitt’s law, as the menu bar opens beside the cursor at all times. Stemming from this, contextual menus are not an arcane secret; there is no strict distinction between a context menu and a standard menu set.
To view the available menu options, position the mouse cursor over the window or icon on which you wish to perform a command, and press the middle button. Menus can be invoked for the Pinboard and its icons, Icon Bar icons (but not the bar itself), folder windows and their icons, and the work area of a document window. Title bars, toolbars, scroll bars and non-work areas are excluded; pressing the middle mouse button over the calculator does not invoke a menu.
Menus typically come in two varieties. Icon Bar icon menus are highly contextual, relating specifically to that icon alone:
Menus generated by a window are generally equivalent to a standard application menu bar, but the root menu may itself contain terminal items including boolean menu items:
However, as context demands, a window may display a different menu according to context; here, a menu relating to the path currently being edited:
Often, the root menu has a submenu reserved for the window’s selection:
All menus have titles and can be dragged, including submenus:
In the screenshot above, each menu has been dragged after it was opened. All window dragging and resizing is live in RISC OS, including dragging menus. Left-click on a standard terminal menu item closes the menu as normal, but right-click issues the menu command and leaves the menus open for further commands; this is useful for ticking multiple items or reverting changes.
Perhaps RISC OS’s most notable interface paradigm is the treatment of terminal (leaf node) menu items. Most graphical interfaces have only two types: commands and boolean properties. Windows and EIKON also feature radio-button menu item groups. RISC OS goes much, much further! RISC OS blends dialog boxes directly into the menu system: many dialog boxes are presented simply as menu items or submenus. This saves on mouse clicks and allows the user to rapidly and effortlessly find the dialog they need. There are several distinct behaviour modes, as detailed below.
Custom menu items allow the user to provide a custom value in a list, such as a custom font size or line width, without needing a separate dialog box.
These menu items appear at the bottom of what is otherwise a normal menu:
They can also appear within some rather deep submenu structures:
To select a triangular start cap in the above example, you can click Triangle or any submenu that follows. To set a custom width or height, position the mouse cursor over the appropriate custom field (but do not click it), delete the existing text (with backspace) and enter a new value. You must then left- or right-click it or press enter to confirm. Enter and left-click will set Triangle as the start cap style and close all the menus. Right-click will confirm the input—which is discarded if you simply focus another menu item—and leave the menus open. This allows you to set both width and height without navigating the menu system twice.
Along the same lines as above, some submenus exist solely to take text input. This need not be numeric; for example, it could be a command:
As noted above, you must not click into the text field during editing. The reason for this is that the text field doubles up as a menu item: after entering your desired text, you then click onto the text to confirm the action. This means that you cannot reposition the text cursor (caret) with the mouse; instead, you must press the left and right arrow keys on the keyboard for this purpose.
One of the most bizarre uses of this is the insert and remove feature of the !Paint program:
This is a feature to insert or remove rows or columns of pixels from the image. You can type the desired number of rows or columns to add or remove, or wave the cursor over the underlying document window: the input box is filled for you. This feature begins to introduce the way RISC OS treats modality. Curiously, this is a counter-example where you can indeed position the text cursor with the mouse.
Submenus can be complete dialog boxes. The simplest of these is the information dialog box:
There are no buttons: simply press escape to cancel it, or put the mouse over a parent menu item. This can become particularly frustrating with menus opened on the right-hand side of the screen. For example, when trying to use the program menus for !Edit, if the cursor passes over the Info submenu entry, the program information dialog box appears and completely obstructs the parent menu:
Submenus can also be conventional dialog boxes, such as Print or colour selection:
Submenus can also be owner-draw items that combine the custom appearance of a dialog with the instaneous response of a menu item:
The above zoom item does not have a confirmation button; the changes to the zoom level – which curiously can be fractions such as 3⁄2 – take place live. Press escape to dismiss the menu.
The above approach is not unique to Acorn; PhAtfiSh sent me a screenshot reminding me that Microsoft use extended menu behaviour in their own products. For example, combo boxes and what appear to be graphical radio buttons:
Windows are in some ways even stranger than menus. Some aspects of them are straightforward: proportional scroll bars, a close box, and a Macintosh-style size box. The top-left widget, taken from the Amiga, pushes the window to the back of the window stack. The top-right widget behaves similarly to the Macintosh zoom button.
RISC OS has little other window management. All windows exist in a big heap, with the only navigation command being the ability to push a window to the very bottom of the stack, where it will get lost under the pile of windows within which you were trying to locate another. There is no Window menu as there is in most Macintosh applications, and clicking a program’s icon on the icon bar does not bring all of its windows frontmost as it does in Mac OS X or when selecting an application from the menu bar in classic Mac OS (instead it is more likely to punish you by opening yet another window). The proliferation of windows is even more difficult to manage than it was in Mac OS; as tedious as the taskbar thumbnail system is in Windows 7 onwards, it is far easier to manage than interfaces that went before it.
RISC OS does support minimise-in-place: hold shift and click a window’s close button to reduce it to an icon on the desktop located at the window’s top-left corner. This is similar to how minimise worked in the original versions of Microsoft Windows. Given this example selection of windows:
Here are the same windows after shift-clicking each one’s close box:
Spaces in filenames are forbidden, and spaces are also forbidden in minimised icon titles, so each icon’s caption is the window title up to the first space. Double-click restores a window, but they do not affect the Pinboard menu unlike pinned file and folder icons. Some minimised window icons contain a file type icon of the related window, but many do not.
A final note: filer windows always open large enough to fit the full path into the title bar:
Window focus is a world unto itself. Operating a window with the mouse does not bring the window to the front: the window remains where it is in the window stack. There is no need to bring a window frontmost in order to use it. For example, you can type into a background window:
To bring a window to the front, click its title bar or size box. Using the right mouse button, you can drag and resize windows without activating them, similar to holding command on a Macintosh.
In the above image, you can see that the background window has a yellow title bar, and this is where it gets bizarre. A yellow title bar indicates that the window has keyboard focus. Not only is keyboard focus unrelated to window order, but it is unaffected by menus, which do not respond to the keyboard at all, allowing you to keep typing while a menu is open:
Very little in RISC OS takes keyboard focus. File system windows do not, for example, nor do menus. The only dialog controls that can be operated with the keyboard are text input fields. Document windows can choose to accept keyboard focus, of course. The !Edit window above keeps the keyboard focus even with menus open, as the menus don’t request the focus.
However, if you open a submenu that does require keyboard focus, the yellow highlight is removed from the parent window:
If you move the mouse cursor back onto the parent menu, the input submenu closes and the document window instantly regains focus, and with it, the yellow highlight. Navigating submenus will often trigger the document window’s yellow highlight to flash on and off rapidly as keyboard focus switches between the document windows and submenus that take keyboard focus, which is quite distracting. Note that submenus that take keyboard focus keep their grey title bars, which is visually inconsistent. Dialog boxes, however, do get the highlight.
If you disable the active text field in a dialog box, the dialog’s yellow highlight will be removed, as it no longer has keyboard focus.
Keyboard focus is not gained by bringing a window frontmost: the keyboard focus will remain with whichever window has the keyboard focus at the time. To give a window keyboard focus, an appropriate part of its content area must be clicked. In !Edit, this is anywhere within the text. In !Calc, clicking the calculator buttons does not assign keyboard focus. The buttons will operate the calculator, but key presses will be discarded or go to whichever window has keyboard focus:
The only way to give !Calc keyboard focus is to click in the calculator’s display area!
Note finally that opening a menu does not alter the stacking order either:
!Edit’s menus appear above !Calc’s window, but the !Edit window itself remains resolutely at the bottom of the window stack.
Unlike various other graphical interfaces, RISC OS also has no concept of always-on-top. Tool palette windows can be buried below document windows (and easily, on the small screens of that era). The Icon Bar can be (and will be) obscured by document windows. However, always-on-top is not always needed in RISC OS. For example, the !Chars application presents a character palette from which you can insert characters into whichever window has the keyboard focus:
Inserting characters into a menu text field is slightly different. Clicking into the !Chars window would snap the menu shut, so you hold the cursor over the desired character and tap the shift key! This approach works at all times, but clicking the characters is generally more convenient.
Dialog boxes in RISC OS are highly modal. Typically, switching to another window, of any application, including the window behind the dialog causes them to simply disappear. Dialog boxes in RISC OS are typically shown as windows with no title bar widgets:
System dialog boxes, however, restrict the mouse cursor to within the window itself, ensuring that they be accepted by the user:
More often than not, however, it appears that regular windows are used instead, even in cases where an ellipsis is used to indicate a dialog box:
In the following example, the top window is a dialog opened via the bottom window’s Set new alarm menu. Although you can return to the parent window and open the menu again, the menu command is now greyed out. The menu item does not carry an ellipsis.
The following window shows a resizable dialog window:
Dialog controls are relatively similar to their Macintosh and Windows counterparts, and there are few obvious gotchas. One particular curiosity is that the text in text boxes (and editable menu items) is always centre-aligned:
The only keyboard navigation permitted within dialog boxes is the ability to cycle between text fields with the up and down arrow keys.
In dialog boxes that contain only buttons, sometimes you are able to trigger the buttons by pressing the key corresponding to the first letter of the caption. For example, when closing a window with unsaved changes, you may be able to press the D key to discard the changes, as shown below:
There is nothing in the window that indicates that this is possible, and it seems to only work half the time, with no clear indication of which programs and which dialog boxes will accept it and when. The text replacement operation dialog box from !Edit contains a large number of buttons, and all of which can be used this way. The clue to RISC OS sometimes permitting this was the redo button being captioned “reDo”, as the R key is already needed by the Replace button.
In these situations, the keyboard focus indication is again badly designed. In both screenshots above it appears that the document window has keyboard focus, but it does not: keyboard focus has been passed to the dialog boxes. Pressing any key not associated with the dialog box will not do anything.
RISC OS does not have standard Open and Save dialogs like other graphical interfaces. The Save dialog is normally presented as a menu, into which you enter a filename:
This menu however is deeply confusing. Clicking OK will yield the following error message:
In order to save a file for the first time, the icon in the Save menu should be dragged into a folder window:
The reason for this is that the text box must contain a full path (e.g. “$.Myfile” to save to the root directory of the default drive). When saving a file that is already on disc, the text field is filled with the full path to the file and the OK button can be used:
This is not obvious, as the error dialog implies that the OK button cannnot be used at all. Note that in the above situation—pressing F3 to save—the Save dialog box is shown as a regular dialog box.
RISC OS does not have Open dialogs of any variety. To open a file with a program other than the default for its file type, the program must be launched first, after which the file can be dragged onto its Icon Bar icon or an open window. Unlike Mac OS or Windows, files cannot be dropped onto a program’s icon in a Filer window. Nor can they be dragged onto a folder’s icon: to move a file into a folder, it must be dropped onto the folder’s open window. More confusingly, files are by default always copied, never moved. To move a file, hold shift while dragging it.
When a program needs to allow the user to choose a file, drag and drop is again used, with the window providing a drop area to collect the file (note that the “Routes file…” button in the first picture opens the chosen file):
Note also that holding shift while opening a file will open it in !Edit as a text document, regardless of whether it is a text or a binary file. For binary files, non-printable characters are shown as their hexadecimal character codes within square brackets, e.g. “” for null. Thus, !Edit appears to be a binary-safe text editor.
File types in RISC OS are stored in the file system metadata similarly to Mac OS. Unlike with Macs, RISC OS made this metadata editable. Each file type has a 12-bit hexadecimal code as well as a brief descriptive name. For example, obey files have type “Obey” with hexadecimal code 0xFEB:
Where a Windows PC would allow the user to choose the file type during save, RISC OS allows for the user to set the file type using other means. For example, !Edit allows the user to choose which type of file to create from its application context menu:
!Edit also permits the type to be chosen while the file is open, although here you are not given a list of possible types and must remember the name of the type or its code:
The type of existing files can be set from the Filer, by entering either the hexadecimal type code (such as “feb” for Obey files) or the type’s descriptive name:
Standard media volumes are referenced by the name of the file system followed by the drive index starting from 0. Each volume has a name, and this name can be used in place of the drive index. For example, an ADFS volume called Spiele4 is mounted in drive 0:
The contents of the disc can be accessed using either index of the floppy drive (e.g. ADFS::0.$) or the name of the volume (e.g. ADFS::Spiele4.$). Note that the file system name appears to end in a colon (e.g. “ADFS:”) while the drive identity begins with one (e.g. “:Spiele4” or “:0”), the directory separator is “.”, the root directory is “$”, and there is an extra dot between the two, e.g. “:0.$”.
It is possible to eject one disc and insert another, and continue to browse the contents of both discs, as the catalogue of each volume is cached in RAM. The use of volume names in the Filer window titles makes this unambigous:
Accessing a file from an ejected disc will prompt WIMP to ask for the required disc to be inserted:
This is very similar to how the Macintosh handled floppy drives, except that Acorn computers allowed manual ejection of discs and did not visibly indicate ejected volumes. Macs would not allow ejected volumes to be explored. Mac OS had no cancel button in the disc insertion prompt: if the Mac no longer recognised the disc when reinserted (which would happen), most users would have to switch the computer off and back on to regain control, as the means to cancel the dialog box (hold command and type a full stop) was not obvious. It appears that RISC OS handled this situation considerably more elegantly than Mac OS.
User-facing applications on RISC OS are directories (folders) disguised as applications, a concept named “application directories”, later adopted by Mac OS X. An application directory is simply a normal directory where the first character of its name is an exclamation mark, hence the presence of that character in the name of every program on disc. Removing the exclamation mark from the name will cause the application directory to revert to being a regular directory. Holding shift while launching a program will instead open the application directory as a normal Filer window so that its contents can be inspected and managed. Here, the contents of !Guile have been opened, and the !Run launch script is displayed:
The effect of launching an application depends on its purpose. Many games run full-screen, and some seem to have no way to get back to the WIMP desktop without restarting the computer. Some utility programs such as the !Chars character selector simply open a window. Most applications simply append an icon to the icon bar; the screenshot below shows the effect of launching !Edit, with the extra icon in the icon bar being the only clue that anything happened:
This new icon in the icon bar has to be clicked to cause the program to appear. Clicking the icon may bring up the program’s window (as with !Configure), or it may start a blank document (as with !Edit). Other programs may prompt for details before creating a new document, for example !Paint will ask for the width and height of the new sprite amongst other information. The idea that clicking the icon creates a new document became a standard behaviour in Mac OS X when an application is running with no open documents. However, on RISC OS, clicking the program’s icon bar icon always has the same effect: if it creates a blank document when the program was first opened, it will always open a new blank document when clicked again, while on the Macintosh it will bring the program’s existing windows to the foreground.
Normally multiple instances of the same program are permitted, but !Alarm only allows itself to be run once:
Like its predecessors, the Acorn BBC Master Series, the Acorn Archimedes started out with non-square pixels in the default 640×256 resolution. The mouse cursor, icons and the system font are all designed for pixels that are twice as high as they are wide. When using a more standard 640×480 screen, this leads to system text and icons having a disturbingly low-resolution look on a screen that otherwise appears relatively high resolution. The screenshot below shows 640×256 in 256 colours:
However, the graphical interface is also capable of rendering high-quality text:
Anti-aliasing works better than expected (true smooth type on a 1992 system), but “sub-pixel” anti-aliasing is not what it seems. The first screenshot below has sub-pixel anti-aliasing disabled, while the second one has it enabled:
Sub-pixel anti-aliasing in this context (at a time that predated colour flat screen devices) means sub-pixel positioning of letters on the screen to achieve fractional letter widths. This feature was also introduced in the Unicode text engine ATSUI in Mac OS 8.5, but since Mac OS before X did not support smooth type, the only result was mis-spaced letters rather like the first screenshot above, but more pronounced. Only with Mac OS X did any mainstream graphical interface provide the smoothly rendered, fractionally spaced type that Acorn accomplished in 1992 or earlier. The disparity between system text and application text, however, is especially clear.
Even more curiously, the system splash screen text is also rendered on the fly, according to your anti-aliasing settings. The two screenshots below show the splash screen with and without anti-aliasing enabled:
By 1997, Apple had got around to displaying a pre-rendered image of anti-aliased text.
One interesting feature of the Amiga interface is that icons were not required to have square dimensions, and commonly were not square. RISC OS does also allow non-square icons, but with more limitations.
The Filer places all icons onto a fixed-size grid. In the default large-icons view, icons are permitted to use an area 86×38 pixels (86×19 pixels in screen modes with rectangular pixels); although there is 90×40 pixels of space allowing for comfortable spacing, only the 86×38 pixel area is highlighted when clicked. Acorn went with 34×34 pixels as the default size of their own icons (34×17 with rectangular pixels). Applications are at liberty to use any size within that space, and indeed many did so, especially games. In fact, they are free to exceed that size, and oversize icons overlap the caption and other icons.
The screenshots below show some custom-size icons in both large and small sizes:
The !Lemings icon shown above is oversize, designed to enclose the icon caption. Neither !Lemings nor !Guile provides a small icon: the caption trick used by !Lemings fails in small icon view and the !Guile icon is so wide that in small icons view its own caption draws over it. Note that although Filer windows are comfortable with icons up to 86×38 pixels, item information windows only expect icons to be around 50 pixels wide:
Editing an icon sprite allows one to set the size to something absurd; here I have taken a copy of !Lemings and made its icon far too big:
Taken to the extreme:
Note that when clicking an icon, RISC OS will only invert the portion of the icon within the expected bounds:
Icon Bar icons are not required to be square either. Unlike with Filer icons, larger Icon Bar icons are given the space they need:
RISC OS permits the interface theme to be modified in various ways. The standard revised appearance—akin to Apple’s Platinum theme—is the NewLook theme, seen here reasonably retro-implemented for version 3.11:
KDE users are likely to be familiar with this theme, as it was created as a KDE theme. Notable omissions from this version supplied with UniBoot include the window backgrounds, menu separators and an anti-aliased full-resolution system font.
RISC OS supports an animated hourglass cursor as standard, via the operating system call
Hourglass_On. Click the animation below to download the cursor as a Windows animated cursor:
- Originally posted on the 14th of May 2007.
- Substantially updated on the 24th of May 2020.
- A basic pictorial overview of the interface can be found at the GUIdebook gallery.
- Further reading on RISC OS can be found on Vincent Lefèvre’s RISC OS page.
- The screenshots are courtesy of the defunct RedSquirrel emulator (I have been emulating the A5000); permission is expressly granted to use these screenshots anywhere.