Jump to page content

Graphical user interface


If, from reading these notes, you conclude that I am off my rocker, you won’t be the first, and you may even be right.

No doubt there is a dozen and one reasons why none of this would ever work, but perhaps somewhere deep down there is a tiny fragment that could be used for something.


Global consistency

Only one out-of-the-box graphical user interface will be offered. This will be chosen as a compromise to suit as many people as possible. This is required to help anyone in the world to support anyone else in the world, by ensuring that as many installations as possible look and behave in an expected manner. Where possible, changes to this interface over time will be as limited as possible.


Instead of a single shell, each component of the UI (window manager, task switcher, application launcher, window theme, folder browser etc) will be a separate program or library. A high-level message passing system will be used to drive the window system. Component processes will register for events and send their own commands to the graphical despatcher. This way, parts of the UI can be swapped out separately (e.g. replace the Windows-style taskbar with a RISC OS-style icon bar or Mac OS-style floating palette.

The various abstract components will include:

Window manager
A program that handles window presentation and behaviour. Separate window managers could offer behavioural models such as Windows (with maximise and minimise), RISC OS (with select/menu/adjust mouse control and send-to-back) and macOS. Since the position of the menu bar (integrated as with Windows, mouse-invoked as with RISC OS and global as with macOS) varies by window model, the menu bar will likely be provided by the window manager. A desire to mimic the style of another system without altering the system behaviour would be achieved by simply changing the theme.
Window theme
A set of definitions for drawing interface components such as window borders, window corners, widget bodies, widget corners, control surfaces etc. While largely vector, bitmapped surfaces would be permitted so that we can have RISC OS-style themes. Changing the theme would restyle the appearance of windows but not change the system behaviour.
Task switcher
A means for providing a way to change task. Possibly you would need several, such as for the taskbar (visible window), alt+tab and win+tab (on demand) and the classic Mac application menu. These could be libraries (for hooking into the window manager) or standalone applications. Separate processes for the taskbar and alt+tab/win+tab would add a bit of noise to the user’s process list, so libraries would add tidiness.
Application launcher
A means for starting applications. Again, this could be a library that taps into the task switcher (start button) or global menu bar (to mimic the old Apple menu) or a fully standalone program (such as how Windows 8 behaves).
Folder browser
A library that presents a graphical view of a file system, used by file managers and Open/Save dialogs. FTP and SFTP software would be expected to register a process-level loopback handler so that they can feed their simulated (remote) file system into the standard presentational model.


Additional bindings include those listed below. Each one by default is bound to a standard utility included with the system.

Internal consistency

Most computer users are “rote learners” rather than “understanders” when it comes to computers. The staggering lack of inconsistency within desktop software generates an excessive level of cognitive load on end users. This is a far worse problem in Windows than other desktop environments. A simple task such as copying text to the clipboard is not a rote learnable task, as every program makes this command available in a different place. Microsoft are incapable of picking a single ribbon design and sticking to it, software vendors almost universally make a pig’s ear out of their attempts to copy it, some applications put the menu bar under a single button, and the rest all still use the legacy menu bar design. Right-click is a trick that could be learnt once and employed everywhere, except for all the places where it doesn’t work.

Apple attempted to bring more order to the desktop with Mac OS X, and this is the correction direction to go in. The intention here however is to go a step further. Where possible, interface concepts such as menus and toolbars should be described in a flexible way that gives the user a choice as to what mode of user interface to be employed. Whether it’s possible to use a single data structure to define a command set that works both as a menu system or a ribbon is unclear and needs investigation. A simple toolbar system like macOS uses would use a command repertoire derived from the master command set from which the menu bar or ribbon is derived.

There is one important caveat here: classical menus have a huge advantage over any other kind of entirely graphical interaction: menus do not require every command to provide an icon. Macintosh software is quite surprising as to the professional quality of icons used, but too many developers will not have the skills or inclination to find or draw a suitable icon for every possible command.

As a note, just as with macOS, the user must be allowed to search for commands. There is no reason why they should not be allowed to execute graphical commands from a prompt, but the macOS approach of showing the user where the menu item is allows the user to achieve in a couple of clicks what would otherwise require not just typing but also an input change from mouse to keyboard and back.

Avoidable sins

The arrogance and stupidity of so many software developers and software houses leads to a lot of avoidable sins:


Modern computer systems display depressingly little synergy, and all too often very little feedback to the user as to what did happen or will happen. The graphical user interface design will resolve this as best as can be practically achieved. Some examples:


Where possible, the user should able to achieve an unbroken stream of input with whichever input device they are using. That is to say, text input notwithstanding, the user should be able to keep their hands on the keyboard or hand on the mouse without needing to keep switching between the two as they work. Each command should have both a mouse and keyboard means to invoke it.


See the RISC OS GUI page for notes on how much better the mouse can be handled.

Window state

State flags include:

Indicates that unsaved changes exist; the window manager is responsible for presenting this information, as different graphical interfaces show this differently. An asterisk in the title bar is a fallback option (e.g. a Windows-like desktop) while a macOS-like desktop would place a dot into the window’s close button.

Additional state information that should be provided for the window manager to use:

Window toolkit

Window layout will be dynamic rather than pixel-positioned. The most straightforward GUI known is possibly Psion’s EIKON UI from EPOC32. In EIKON, all controls in a dialog box are arranged vertically, except for the buttons. Each new control is placed below the one above. For example, the following keyboard shortcut handler for Control+A shows the About dialog box in LBShips:

PROC cmdA%:
	dInit "About LBShips"
	dText "", "Lecture Battleships for the Revo " + KVersion$, 2
	dText "", "Daniel Beardsmore, 2003", 2
	dButtons "OK", 13 + 256

Although unachievable in OPL, dialog boxes with more content than will fit on the screen were divided up into tabs. (All OPL would have needed for this was a simple “dTab” command to start a new tab, but OPL had some serious omissions compared to the C++ API.)

Where possible, window layout is to be achieved using the minimum amount of presentational control, using automatic control placement.