The Wimp

Iconbar Priorities

Iconbar priorities have been vague at best, with some usages being declared to be the 'easiest way to do things'. In addition to this, some entities such as ADFSFiler have used incorrect iconbar priorities by accident. This particular case means that Floppy discs do not appear where they are documented to appear in the PRMs. Floppies are documented to appear at &60000000. They actually appear at &70000000. ShareFS used a priority of &68000000. This results in a mismatched iconbar, where the three cases of documentation, logical appearance and prior use cannot be resolved simultaneously. Thus, it has been decided to clarify the usage of parts of the iconbar. This should make for a more logical system, and the possibility of multi-tier iconbars and other such changes.

The iconbar should be viewed as:

   <-- Devices and drivers                 Applications and utilities -->
    +----------------------------------------------------------------------+
    | Object sources/ | Source/Sink  |        |     User     |    System   |
    |          sinks  | Controllers  |   Gap  | Applications | Controllers |
    | RO -> RW -> WO  |              |        |              |             |
    +----------------------------------------------------------------------+
     \_______________/ \____________/          \____________/ \____________/
         Prioritised         Not                      Not        Prioritised
                         prioritised              prioritised
            [1]              [2]                       [3]            [4]
   

[1] Object sources and sinks

These are icons for devices to which objects can be sent or retrieved from. They are ordered logically from read only devices on the left through read/write devices to write only devices towards the right. Alongside write only devices are the volatile devices; those devices whose contents are not likely to remain permanent from session to session (or even within a session).

The full ordering is:

In addition, there are "accelerator" applications which need to be considered virtual devices.

All devices in this category should have a name underneath, ideally identifying the medium name with which they are associated. If no medium is associated (eg. a removable, or unconfigured device), they should display the medium name (eg. Zip disc, Printer, LanMan, etc), or a generalised medium identifier (eg. the drive or port number). These applications should not provide a "Quit" option.

[2] Data source / sink controllers

This is basically a place for internet servers, connection systems and other network utilities to live, as well as local servers. Like [1], these should have their name under them. Samba, TelnetD, Newsbase, InetSuite, WebServe and Netplex would fall into this category. These will grow to the right when the user loads a new controller. These applications should provide "Quit" options. Most should provide a status window, and many will provide configuration windows.

[3] User applications

This is where user applications appear when loaded. They will grow to the left as they are loaded, taking up the free gap space. These applications should provide a "Quit" option. They should not have text placed under them unless they are configured into a particular state that must be described. Such applications are discouraged unless there is a genuine need.

[4] System control applications

This is where system control applications live. These are things that will control the machine, the desktop or the way in which the system works. Initially, this comprises the Task Manager and Display Manager. Because of its high priority, Help lives here too. This may be rationalised in future.

These categorisations amend and expand on documentation provided in the PRMs. The intent is to clarify the system for a logically organised iconbar, with clearly defined positioning for components, and whilst retaining the current state wherever possible.

This documentation is copyright 3QD Developments Ltd 2013 and may not be reproduced or published in any form without the copyright holders permission. RISC OS is subject to continuous development and improvement as such all information is reproduced by 3QD Developments Ltd in good faith and is believed to be correct at the time of publication E&OE. 3QD Developments Ltd cannot accept any liability for any loss or damage arising from the use of any information provided as part of the RISC OS Documentation.

HTML document version 1.03 3rd November 2015