Distribution: COMPANY CONFIDENTIAL
Project: Applications
Issue: 0.09
Author(s): Steve Cormie
Date: 02-Apr-96
Last Issue: 0.08
0.01 SMC 04-Mar-96 First created.
0.02 SMC 12-Mar-96 Filled in some detail.
0.03 OL 21-Mar-96 New additions and changes.
0.04 SMC 22-Mar-96 Reorganised in light of Owens input.
0.05 SMC 25-Mar-96 Added example main window.
0.06 SMC 25-Mar-96 Repositioned toolbar menu button.
Added Fonts section.
0.07 SMC 02-Apr-96 Updated for new UI.
0.08 JS 21-Jun-96 Added requirement for Message_AllWindowsClosed
0.09 JS 01-Jul-96 Added message number for Message_AllWindowsClosed
This document specifies the requirements which an application intended to run on the Network Computer model 1 must comply. There are also some recommendations on features which are not compulsory and guidelines on general user interface design.
Italicised text is used where issues are still to be decided or where contents are liable to change.
This section specifies features which an NC application must posess. As a starting point, applications must conform to the general structure of a RISC OS application ie. have a !Boot file if necessary, have a !Run file etc.
Applications must define icons for themselves and the document types that they require so that they can be represented in the NC filer. These are provided in the traditional RISC OS way ie. in !Sprites files.
Because of the limited display area provided by a television, NC applications must use full screen windows with no window furniture ie. title bar, icons for back, close, toggle size, adjust size, scroll arrows or scroll bars. In addition to this the modes used on televisions are often interlaced and overscanned which means that not all of the screen may be visible on the television display. This means that application developers must ensure that all user interface elements eg. on toolbars, are visible on both PAL and NTSC televisions.
Not all of the application's main window work area may be visible at any one time and the lack of scroll bars means that an alternative method for window scrolling is required eg. keep the active area on screen (caret), provide cursor key scrolling, scroll when mouse pointer reaches the edge of the screen etc.
In the future it is hoped that when connected to a monitor it is still possible to run in a windowed mode ie. with window furniture. The mode of operation to use can be determined when the application starts up by reading the flag which specifies whether a television or monitor is being used. This is not a requirement at present and applications are expected to run full screen even on a monitor.
The NC is capable of outputting a screen image to either a monitor or to a PAL or NTSC television. When a screen image is displayed on a television there can be problems with interference between highly contrasting horizontal lines which are next to each other eg. a line of white followed by a line of black (quite common in desktop displays). This can result in a shimmering effect which we have named "twittering". This effect can also be caused by a dense contrasting pattern eg. a black and white dither pattern to approximate grey.
A software module has been created which provides a SWI which applications must call to "anti-twitter" any areas of their windows which they redraw. The algorithm used works by averaging horizontal lines of the screen area being processed and is destructive of screen contents. This means that an area of the screen must not be anti-twittered more than once.
Anti-twitter should only be applied when a television display is being used and is described fully, along with APIs for anti-twittering, in the Anti-twitter Software Functional Specification.
It may also be necessary to redesign toolbar buttons, or icons in general, which suffer from twittering (or are poorly designed).
It is up to individual applications what features they wish to make accessible via the toolbar. However, all toolbars must have a close button and if a menu tree is supported then a menu button is also required.
A basic set of toolbar buttons for common operations is available from Acorn Network Computing which should be used on application toolbars and used as a basis for designing buttons for other functions.
If an application has more than one window then the size of the toolbar should not change between windows. Ideally, the button set should not change either but it is recognised that this may not always be possible or even appropriate.
As an example, this is how a word processor toolbar might look:
All windows must have a close button which must be placed at the top left corner of the toolbar. Clicking on this button closes the application window. If the window being closed is the last window which the application has open then the application must quit and free up any memory used. If the window contains a document with changes that have not been saved then the application must display a standard Discard, Cancel, Save dialogue box before closing.
If the application supports a menu tree then the application must provide a menu button on the toolbar. This button should be placed at the lower left corner of the toolbar and when clicked on a menu should pop up below the toolbar (clicking the middle mouse button should no longer cause the menu to appear). The menu will look and feel like existing RISC OS menus but will not be movable (this will be handled by the Window Manager), clicking on the background window will cause the menu to disappear. The Window Manager will anti-twitter the menu.
As there is no RISC OS icon bar, any important icon bar menu operations (particularly configuration options) must be made available in the main window menu. There should be a strict separation of machine configuration and user preferences (this should not be an issue for most applications).
If an application wishes to transfer data between its own windows or between itself and another application then it must support the RISC OS global clipboard protocol as specified in the Support Group Note 240 - "The RISC OS Selection Model and Clipboard". This will usually also require cut, copy and paste buttons on the toolbar.
Many applications may require a title/status field to display the name of the current document or some other important information. As no standard title bar is provided this should be implemented using a display icon at the top of the toolbar.
Some toolbar buttons may provide immediate response eg. a Bold icon in a word processor, while others may open a dialogue box giving the user a series of choices.
Dialogue boxes should be created along the guidelines issued in the RISC OS Style Guide, however they should always open in the middle of the screen display and will not be movable (draggable). They should not have icons for back, close, toggle size, adjust size, scroll arrows or scroll bars but they should always have a Cancel button. The Window Manager will anti-twitter dialogue boxes.
The NC desktop font ie. the font which is used in all text icons rendered by the WindowManager, can be assumed to be Homerton.Medium at 14 point for the purposes of designing icons and dialogue boxes.
A filer application forms part of the base application set of the NC ROM. This is used for general purpose filing operations and can be used as described in the NC Filer Software Functional Specification. This filer must be used by applications which save or load files. Traditional RISC OS save boxes must not be used.
Memory on the NC is a scarce resource. There will typically be either 4M or 8M DRAM but system resources, including screen memory, must be taken from this. Applications must not use any more memory than is absolutely necessary and care must be taken to ensure that there are no memory leaks. In particular, applications should ideally start and quit without using up any extra memory. If this is not the case then a weaker goal is to not use up any more memory the second time it is started and quit eg. this might be the case if an application leaves modules in the RMA.
Applications can expect there to be a writable place where configuration or state information can be saved on a network. This area will be pointed to by the system variable <Choices$Write> and will be allocated on a per-user basis (although this is not important to individual applications). Applications should create an application specific choices directory within the directory indicated by the system variable and store configuration information there. Note that there may not always be a network which allows write operations so saving configuration information must fail gracefully with an appropriate error.
!System and !Scrap will exist but may be very slow. Their use during application operation is discouraged (use of !System at application initialisation is permissible).
At present we do not plan to implement traditional RISC OS interactive help but it is hoped in the future that we will be able to include it using bubble help (like the Macintosh). In the meantime, an application should either provide interactive help in a display icon on the toolbar which is updated as the mouse pointer is moved around or should provide some form of on-line help.
Message_AllWindowsClosed (&4D301) 0 message size (24) ... 16 Message_AllWindowsClosed 20 Flags All bits reserved (must be 0)This allows (for eg) HTML-creating modules to update their pages/frames when the top-most application quits (or closes all its windows) and exposes old pages.
This section provides some general recommendations and notes on developing applications for the Network Computer. These are not compulsory requirements.
The NC does not have an on/off switch. Instead it is powered continuously (like a video recorder) and has a standby mode. It may be a requirement that applications save some sort of state when the NC is put into standby mode but this has yet to be decided.
It may be necessary to provide some form of file locking where the same file can be accessed and edited by multiple users. This may require cooperation from the applications concerned, probably in the form of a SWI call to lock and another to unlock, although this has yet to be decided.
It is possible that file name syntax may change in future. If this is the case then it is likely to move towards a more Unix-like or URL-like syntax. Applications should treat a file name purely as a string and should not try to parse it if at all possible.
Monitor screen depths are not as great as television screen depths due to a larger screen area. This may affect applications which make assumptions about what screen depths are available.
Screen refresh rates will be very variable so care must be taken with time dependent applications (where the application's notion of time is related to VSync for example).
In order to run more applications in a small amount of memory the operating system may be modified to compress application Wimp slots which are not being used in order to free up some more pages for the rest of the system. This will not be a problem for applications as they will not know about it but in order to make this effective, applications should use as few Wimp events as possible, particularly null events.
The Network Computer ROM contains a new font manager which supports anti- aliasing with the window background rather than just a specified background colour. This is specified by setting bit 11 of R2 in calls to SWI Font_Paint. There is a small performance hit so this feature should be used selectively where possible eg. a simple text editor or word processor does not need to use this feature if it only ever draws text on a solid background.
Traditional RISC OS fonts may have to be renamed to reflect what they actually are. This should not be a problem for most applications which simply provide a list of enumerated fonts to choose from. However, application developers should be aware that traditionally named RISC OS fonts may appear to be not present.
Television screens will require larger font sizes than monitors, typically a 120% to 125% magnification.
The Network Computer is being developed in partnership with an American company which means that application developers may be asked to produce USA localised versions of their applications. Localisation includes message and template file translation (mostly minor spelling differences), localisation of dictionaries etc.
The NC ROM contains a sub-set of traditional RISC OS ROM modules. In particular, application developers should be aware that there are no RISC OS filers and no TaskManager.