An architectural model of a window manager is presented. Some commercially available window managers are compared in relation to this model. Specific attention is given to the window managers supplied by SUN, APOLLO, and ICL (PERQ PNX).
The Science and Engineering Research Council has adopted a coordinated plan to ensure that the UK academic community makes the best use of the resources available to it, especially its limited manpower. The Council has therefore decided on a policy of creating a common hardware and software base to act as a nucleus for future developments in single user workstation practice. Initially, the common software base is Pascal and Fortran-77, running under a Unix operating system, and using the GKS graphics package. The common hardware base consists of ICL PERQ and SUN workstations, linked locally by Cambridge Ring or Ethernet, and nationally by an X25 wide area network. The Common Base group at RAL is responsible for coordination, support, and software development for the Common Base Policy.
This paper was prepared for the Alvey-sponsored Workshop on window management. It is deliberately contentious at times, with a view to instigating discussion and clarification. The information on window managers has been extracted from the suppliers' manuals, augmented by RAL experiences in using the systems. In some cases this experience is limited, and the information given here may be incorrect, and is certainly incomplete. This paper should not therefore be regarded as definitive.
Commentary on some other window managers has been added subsequent to the Workshop, derived from presentations and discussions there. These are the Whitechapel MG-1 window manager, Sapphire (PERQ Accent), and the Andrew system developed for SUN workstations at Carnegie-Mellon University's (CMU) Information Technology Centre (ITC) in collaboration with IBM.
A conceptual model of window management is presented, and some commercially available window managers compared in relation to this model. Specific attention is given to the SunWindows system, the APOLLO display manager, and the ICL PERQ PNX window manager. Specific references are not given, but a bibliography of papers of interest is included in Chapter 24.
The comparison is made in the light of two rather different goals, which, broadly speaking, characterize two classes of window manager to be found today. One function of a window manager is to provide a means by which a user can switch attention between multiple independent tasks at will. This corresponds to the single window per session model. The other is to provide support for complex applications which wish to use multiple display windows to support a powerful and flexible dialogue. This corresponds to the many windows per session model. This is typified by systems such as Smalltalk-80 or Interlisp-D. Our goal in the Common Base group is to combine these two facilities, providing the protection required to run mutually ignorant applications, while allowing for the level of integration of facilities offered by such systems as Star, both within and between applications (where achievable). The term adopted for this is the Integrated Open System.
This model of window management is presented with the intention of identifying the architecture and components of a conceptual window manager. The model is generated partly by abstraction from some existing window managers, and partly from a personal viewpoint.
The purposes of the model are to provide a context for comparison of window managers with widely differing functionality, and to provide a strawman model for discussion at the Workshop.
The model is described in terms of the concepts supported by the model, the components of the model, and the architecture.
This section is primarily intended to define the terms used in this paper: terminology differs considerably according to subject area, for example, the terms window and viewport have quite specific meanings in the area of graphics standards, but are used differently in other areas. Along with these concepts, some issues are listed, which highlight differences between window managers, and interfaces to other components of system software.
Icons are deliberately omitted from this list. All of the systems studied which support icons do so differently in terms of visual presentation, application interface, and implementation. There does not appear to be a consensus about the conceptual function of icons, nor an adequate framework for comparison. The only common characteristic is that they are small!
The components described here do not necessarily refer to specific software components. They are identified for purposes of exposition.
Figure 3.1 shows the above components in schematic form, with the connections between them. The boundaries between components are intended to signify information hiding. For example, the WMS is the only part of the system which has information about the position and rank of all of the windows. Connections represent use of a service provided through a well-defined interface.
The comparison given below attempts to show how the different systems implement windows, by discussing the placement of functionality relative to the components of this model. The issues which need to be resolved to convert this model into a specification for a window manager are:
These issues need to be considered in the light of the performance implications, the configurability and extensibility of the window manager, and concerns of portability and device independence both of client applications and the window manager itself.
This section provides a comparison of some window managers, in relation to the model described above. They are compared in terms of support for the concepts outlined above, and the placement of responsibilities and services within the implementation. The segmentation of the implementation by address space boundaries is discussed, as this has effects on sharing, protection, and performance. The detailed comparison is in terms of the overall architecture, and the interface provided to application programs, but some comparative observations are made concerning the user interface. Occasional points will be noted to illustrate inconsistencies and other minor oddities of particular implementations.
Information on the APOLLO display manager is rather sparse, as it is distributed over several manuals, and there is no architectural overview. It is not possible to determine how the underlying implementation is structured, as the only available information relates to the use of specific functions. The SUN manuals provide an abundance of information at the user and programmer level, but no architectural overview was available.
Much of the information given here was obtained during the implementation of the Spy editor on PERQ PNX, and its subsequent porting to the SUN and Whitechapel MG-1 machines. Spy was not ported to the APOLLO, although it was hoped to do so. Study of the manuals indicated sufficient restrictions and programming difficulties that the effort involved was estimated at three man-months as a minimum. SPY is a window-based text editor for Unix systems developed by the Common Base group at RAL, with the goal of making as much as possible visible to the user. SPY is modeless, using graphical selection of command operands, after the style of the Small talk editor, and editing commands are almost exclusively invoked using the mouse, with a mixture of fixed, pull-down, and pop-up menus. Uniform ways of cancelling actions before completion are provided, as is a single-level undo facility (which will also undo global changes). The keyboard is used for input of new text, but backspace, delete word, and delete line commands are supported on control keys for compatibility with the Unix terminal emulator. It supports concurrent editing of multiple files, with each shown in a subwindow. The user moves between files and performs copy and move functions on arbitrary blocks of text simply by moving the mouse appropriately, using a postfix command syntax. Unix regular expression searches and substitution are provided. All text, including filenames and search/replace patterns, is edited in the same way with the full set of commands available.
The more unusual characteristics of SPY which are of interest here relate to the questions of feedback and dynamic display. Techniques of press-feedback-release-action are used, which are by now common in window-based systems. As in Smalltalk, the range of the selection is highlighted during the draw-through action by the user. Continuous rate-controlled scrolling is supported. During scrolling and editing, SPY provides many graphical representations, dynamically updated in the inner loop of the interaction techniques. Such displays show the visible portion of the file relative to the whole, the position of the selection, the current line number, and the position of markers (as in James Gosling's Emacs). Space allocated to subwindows is reapportioned by dragging title bars, which may slide over each other, or nudge others along. Given the high speed of RasterOp provided by PERQ PNX, these techniques lead to a comfortable, fast, and effective user interface, by showing the effect of an action to the user before the action is completed.
SPY is therefore a demanding test of the ability of window managers to support highly interactive applications. Some minor points arose during the Spy development, and are worth noting:
Window managers affect the user interface both in the functions provided for manipulating windows, and in the constraining effect they place on applications.
All of the window managers provide functions to create, destroy, reposition and resize windows, and to adjust the depth order (ie move to top or bottom), but use differing techniques for their invocation. The APOLLO display manager provides many commands, which may be typed to a special window, or bound (by profile) to function keys or mouse button transitions. The current cursor position is used by those functions requiring coordinates. PERQ PNX and SunWindows provide popup menus for these functions. SunWindows creates windows in a default position and size, which is usually obscuring the window the user was last working in. PERQ PNX prompts the user for a rectangle defining the window. As an anachronism, PERQ PNX maintains a window manager window to which the user may type commands to invoke the functions. This is also used for error messages, and a confirmation (type y or n) which is required when terminating the window manager. (This means that the user cannot terminate the window manager if the keyboard is broken.) Both PERQ PNX and SunWindows provide accelerators, which do not require menu selection, for the pop and move functions. In addition, PERQ PNX interprets the pop function as a push to the back if the window was previously entirely exposed. Sapphire provides several techniques for the same function: pop-up menu for novices, accelerated forms using differing mouse buttons in the title bar, and control key sequences for experts. The MG-l uses window controls on the window borders, in the style of Macintosh, but requires the user to type a command to the shell to create a new window. The latter means that if all windows are busy, the user cannot create another, which seems to lose much of the benefit. The Andrew window manager is a tiling manager: windows do not overlap. Window position and size are initially determined by the window manager, but the user may adjust the boundaries. Windows are only created by invoking programs.
Keyboard input is directed to the window containing the cursor position on both the SUN and APOLLO, but is directed to the currently selected window on PERQ PNX, which leads to frequent errors, especially since newly created windows are not selected by default. PERQ PNX requires the user to select a window by clicking a mouse button before he can communicate with the application owning the window. Such activities as cut-and-paste between windows therefore require an extra click, and cannot be achieved through a dragging action. This constrains the ways in which applications can use multiple windows and provide efficient interaction techniques. When the cursor moves out of a window, mouse input is directed to the window manager until a window is again selected. The appearance is therefore asymmetric, and leads to phenomena such as falling out of windows, causing difficulty. The benefit is that any point on the window may be identified for functions such as move or pop, rather than only the border being usable. Sapphire and the MG-l require the user to select a window for keyboard input, known as the listener. Mouse events are directed to the window containing the mouse position. Andrew allows the user to specify through a preference file whether keyboard input should follow the mouse, or require a select action.
We have seen no mouse-driven interactive programs which run within a window on the APOLLO: the demonstration programs all work by temporarily taking over the entire display. Pads (the APOLLO equivalent of a terminal window) are keyboard-driven, although the cursor position may be moved using the mouse. The cursor normally resides on a character cell, and the shape is changed to a blinking rectangle of that size shortly after the mouse stops moving. It would appear that writing an interactive program which will coexist with others is very difficult to achieve. Very recently, APOLLO have demonstrated a Dialog Manager, which provides the kind of user interface discussed here. This indicates that the problems are not insurmountable, but quantification of the effort needed is not available.
The systems studied have differing performance characteristics. SPY was developed on PERQ PNX, which has a very high speed RasterOp function, enabling smooth dragging actions. The APOLLO DN550 has equivalent performance to PERQ PNX, but other factors prevented the port. When SPY was ported to the SUN and MG-l, actions such as dragging subwindow title bars became unsuitable as the response time increased sufficiently to interfere with the user's hand-eye coordination. (It should be noted that beta-test versions of the MG-l hardware and software were used, and the performance is expected to improve considerably with time.) Sapphire and Andrew use a low bandwidth communication path from clients to the window bitmap, and therefore dynamic feedback cannot be implemented by clients; only that supplied by the window manager itself is sufficiently fast. The performance characteristics also show in the visible speed with which menus appear, but this does not significantly degrade the interface. Andrew has some experimental mechanisms by which applications can download procedures to perform application-specific echoing, but this is at the expense of sacrificing protection.
A second point about dynamic feedback is that if redrawing is performed directly on the display bitmap, the flicker becomes very disturbing. It is preferable to assemble the picture in an off-screen bitmap, and copy it to the screen, so the user sees the updates apparently instantaneously. This phenomenon might well modify implementers' perceptions of the performance tradeoffs. An alternative is of course to double-buffer the display, and switch buffers during vertical retrace, but this entails severe difficulties in synchronizing between multiple applications.
The SunWindows system supports three layers: the Pixrect layer providing low level pixel manipulation functions, the Window layer providing a hierarchy of overlapping windows, and the SunTools layer, providing for the interactive creation of applications and associated windows. The SunTools layer requires that applications conform to a particular style of control structure, and supplies many of the functions of a User Interface Management System (UIMS). Windows are linked in a hierarchical structure, overlapping their parent and older siblings. Windows are constrained to lie within the bounds of the screen, or the parent window in the hierarchy. Different classes of subwindow are provided, to support text, graphics, option forms, and the like. Overall, the window system provides a rich and perhaps over-complex set of functions.
The APOLLO display manager provides character stream interaction via pads (see below), and allows application programs temporarily to take over the display space associated with a pad to perform graphical output and input. Arbitration between competing applications is achieved through explicit acquisition and release of the display and input devices. Windows are created on command from the user, in which case a command interpreter is invoked, or on request from an application, in which case there appear to be some limitations on the functionality.
The PERQ PNX window manager provides the abstraction of a virtual display and associated input devices for each window. Applications may update window images without concern for interference with others. A separate application process performs the functions of creation, deletion, moving, ranking, and resizing windows on command from the user. When a window is created on request by the user, a command interpreter is invoked (the Unix shell), to which further commands can be given to invoke other applications. PERQ PNX provides a kind of special file, which contains the attributes of a window which will be created when an application opens the file. Facilities are provided for creating these special files. This is the only way of creating windows from application programs. A further complication arises, in that one of the stored attributes determines whether multiple opens of the same window special file each create a new window, or share the same one. Windows may be partially off-screen.
Andrew provides a non-occluded rectangular portion of the display, but the client requests for resources (eg size, number of colours) are treated as hints by the window manager. It is normal for the window manager to request that the client redraw the window contents as a result of rearranging the windows. Sapphire and the MG-1 support retained windows, where the client is unaware of redraw activity.
All of these systems provide a number of functions to construct images, including BitBlt or RasterOp, line drawing, text drawing and the like. These may be performed on the display, in windows, or in bitmaps in off-screen memory. SunWindows additionally supports a variety of functions such as replicated texturing, and stencil functions. APOLLO supports a large number of functions typical of graphics packages, including polygonal area filling. These primitives are invoked by calling library procedures or system calls. On the SUN and APOLLO, the display frame buffer is mapped into the application address space, and the library functions directly modify the bitmap, requiring processes to lock out each other explicitly to avoid interference with the cursor image. On PERQ PNX, the window bitmap is held in the kernel address space, and is modified by the kernel when the system call is invoked. The cursor image is held in a separate bitmap, and does not interfere with graphical output.
All systems assume the characteristics of a memory mapped raster display. SunWindows and APOLLO place the details of device access (control registers etc) in the client address space, in a library. Here too is the knowledge of the number of bits per pixel. PERQ PNX, MG-1, and Sapphire place these details in protected server processes, or in the Unix kernel, but the client is aware that the display only supports one bit per pixel. Andrew provides a set of output primitives, and the client knows nothing of the bitmap characteristics. All systems use device coordinates, but libraries are provided (such as GKS) to perform world coordinate transformations.
Sun Windows provides an event queue, with events triggered on change of state of input devices (including mouse position and elapsed time). Events may be triggered when the mouse enters or leaves a window. SunWindows reports only the change of state of the device in the event record, which allows applications to lose track of the complete state of the devices, and get out of step. The SUN supports a three-button mouse with the buttons separately encoded, and either an ASCII-encoded keyboard, or a completely unencoded keyboard with each key state separately detectable. SUN provide the 'select' system call to determine if input is available on any of a set of file descriptors.
The APOLLO supports a three-button mouse, and an encoded keyboard. Events are enabled in a similar manner to the SUN, but it is not clear if they are queued, or only monitored when applications request input (cf GKS REQUEST mode input). Locator events may be enabled, provided the display has been acquired (which prevents other applications from accessing the display), but the application is responsible for tracking the cursor to follow the mouse.
PERQ PNX provides full support for the GKS input modes (SAMPLE, REQUEST, EVENT), with a three- or four-button mouse, and an ASCII-encoded keyboard. Events may be triggered by mouse movement, button press or release, key depression on the keyboard, or elapsed time, but time is only counted while the window is selected (see below). The complete state of the input devices is reported with each event, including the mouse position in three different coordinate systems. Applications may request that a Unix signal be sent when an input event occurs, so that they need not poll. When the size of a window is changed, a signal is sent to the process(es), but an event is not generated, so that synchronous processing is made harder. A level of indirection is maintained, so that physical mouse buttons are mapped to virtual (I hesitate to say logical) buttons.
The MG-l provides an event queue containing information about physical key and button transitions, with mouse coordinates and a timestamp attached. The client may specify which classes of action are to cause an event to be queued. Andrew encodes mouse events as a virtual keyboard character, and the client then reads the associated mouse data. Sapphire translates keyboard and mouse events into abstract events, through a client-supplied table, but this is insufficient to support menus and pick devices completely, and feedback is not supported.
In all cases, emulation of logical input devices such as pick and choice devices is left to higher levels of software, although some library functions are provided to support menus.
SunWindows supports subwindowing through its hierarchical structure of windows. The APOLLO allows pads to be divided into panes, but leaves subdivision of graphical windows to higher levels of graphics packages. PERQ PNX provides no support for subwindowing, leaving it to applications or graphics packages. All systems provide support for application-defined clipping rectangles, which helps in implementing subwindowing as a higher layer.
The MG-l supports windows constructed from a number of panels, each with its own bitmap containing the image. Some panels in a window are used by the window manager for the border controls, and the others are used by the client for image display, scrolling controls etc. Similarly, Sapphire constructs windows from a number of viewports, which may be separately addressed by clients.
All of these systems provide support for bitmaps to generate and store off-screen images. PERQ PNX provides a complete bitmap for each window, and another for the screen, although terminal emulator windows are optimized, and only the characters are stored (see TTY emulation below). These bitmaps are stored in the kernel address space. Off-screen bitmaps may be allocated in the application address space. PERQ PNX requires a file descriptor for an open window to be specified for graphical output, even if both the source and destination are memory bitmaps. Also, RasterOps cannot be performed between windows, as only one such file descriptor is given.
The APOLLO requires the application to acquire the display prior to graphical output. If the window is partly obscured, the window may be brought to the front automatically, or the application may be suspended until it is unobscured, or a list of visible rectangles may be determined (at the application's option). It is the application's responsibility to clip its output to the visible region.
SunWindows maintains a single bitmap for the display, as does Andrew, although clients may request off-screen bitmaps. The MG-I provides a bitmap for each panel, stored in the application's address space. Sapphire and the BUT (Teletype 5620) subdivide windows according to the overlap conditions, and provide a bitmap for each portion, stored in the server address space.
The APOLLO provides for a stream interface through pads, which are transcript files which the user may edit to supply keyboard input to applications. Support for cursor-addressable virtual terminals must be done by applications needing them, using raw mode for the keyboard input.
Sun Windows provides for virtual terminals through the SunTools layer. A separate process acts as the terminal emulator, allowing programs written for VDU terminals to run unchanged. The same technique is used by Andrew.
PERQ PNX provides limited terminal emulation in the Unix kernel. The same file descriptor is used for both character stream I/O and graphical I/O. This causes some confusion when graphical programs and terminal I/O interfere with each other, and complicates the problems of modalities in the input system. For example, terminal input is normally line buffered, and this determines the triggering of keyboard events when enabled for graphical input. The keyboard characters are stored in a separate queue, although events in the graphical input queue indicate that a key has been pressed. This potentially allows time ordering of events to be lost.
Sapphire provides a centralized typescript service which provides terminal emulation for clients. The MG-1 provides a default (VT100) emulator in the Genix kernel, but implementers may provide additional emulators as user processes.
In the SUN and APOLLO systems, the screen is shared among competing applications by explicit locking by application programs. In the case of SunWindows, this is performed automatically by the graphics library. On the APOLLO, the application must explicitly acquire the display. SUN provide a means of batching updates, to avoid costly locking calls for each primitive. Andrew serializes remote procedure calls by processing each message from any client to completion.
SUN and APOLLO require the client application to redraw portions of their windows which become unobscured (called damage repair) or are read back (called fixup, eg for scrolling). Sun Windows optionally provides for bitmaps to hold obscured portions of windows, but the support is incomplete in that they are not automatically updated when the window size is changed. Normally, graphical output is clipped to the visible portions of windows, and the remainder is discarded. Severe asynchrony problems can arise when redraw requests occur during client computation or display update.
PERQ PNX transparently updates the screen from the window bitmaps. Functions are provided to suppress this update to improve performance of batch updates, and these can also be used to suppress update of the screen until a complete image has been drawn, to eliminate distracting flicker. Display damage repair is performed totally transparently by the window manager, and fixups are not needed as the window bitmap is used for these functions.
PERQ PNX input events are directed to the currently selected window (specified by the user by pressing a button while pointing at the window), but mouse events may be directed to the window manager interface process, leaving the keyboard connected to the window. In order for the mouse to be connected to a window, the application must enable graphical input, and the user must subsequently select the window. When the mouse leaves the window, mouse events revert to the window manager interface process. Re-entering the window does not reselect it automatically.
At the SunTools layer, control is retained by the tool library functions, making it difficult for an application to wait for either user activity or some other external event (eg network activity). SUN input events are directed to windows according to the set of event types enabled, and the window(s) containing the mouse position at the time the event was triggered. Event types may be enabled differently at different levels of the window hierarchy.
On the SUN, interactive creation of windows (eg to invoke a new task) is performed on the user's behalf by the Tool Manager. Each tool has a subsidiary process which responds to input events on the window borders to provide for moving, resizing, and ranking of windows.
PERQ PNX provides complete protection between windows. Output is always clipped to the window bitmap, and windows can only be read by applications which have a file descriptor for them, or for the entire screen (which may be protected). The window manager interface process uses a private interface to the kernel to perform the window manipulation functions. These are not available to applications, which protects the user from rogue programs, but prevents applications from providing aids to the user (such as popping a relevant window to the top when appropriate).
SunWindows and the APOLLO rely on good behaviour on the part of the graphics libraries and applications, which is to remain within their windows and avoid interfering with each other. The entire screen may be read as normal memory. Even if the application clips to its own window boundary, it may read back portions of another's window which overlaps it. Tools may perform window manipulation functions such as popping to the top.
Andrew, Sapphire, and the MG-1 are fully protected. The MG-1 permits a client to specify the listener, provided it has access to the current listener.
Protection of the window manipulation functions (pop, move etc) is achieved in PERQ PNX, Andrew, and the MG-l by restricting access to the software interface for these (ie by restricting functionality). SunWindows and the APOLLO are unprotected in this respect.
SUN, MG-1, and PERQ PNX use Unix file descriptors to access windows, which are private to the owner and its children. They also provide global names of special files, which may be opened by unrelated processes. Client tasks are identified by their process identifier, and process group identifier.
The APOLLO provides a window number. It is not clear how this can be used by other processes. Sapphire and Andrew use IPC (Inter Process Communication) ports and sockets respectively to identify windows.
None of the systems provide support for grouping of windows so that they can be manipulated together (eg brought to the front).
The SUN system places most of the functionality in the application address space, and uses system calls for locking. Unix signals are sent to the application to indicate the need for damage repair etc.
PERQ PNX places almost all of the functionality in the Unix kernel, including the terminal emulator but not the window manager interface process. System calls are used by the application to perform graphical output, and signals are sent to the application to indicate when a window size has changed. Clients may request that a signal be sent when an input event occurs, but size change signals can only be sent asynchronously.
Figures 3.2 to 3.5 show the architectural characteristics of these systems in relation to the model shown in Figure 3.1. There is no figure showing the APOLLO architecture, as insufficient information is available.
Communication between applications and the kernel occur by system call and signals. PTY channels are implemented as pseudo-devices in the Unix kernel, and appear as normal terminals to the application. Sapphire uses asynchronous message-based IPC for communication between processes. Andrew uses stream-based IPC, and batches messages to improve throughput. Messages requiring a reply cause the client to wait until the stream has been processed, and the reply received. Normally, all messages are buffered until such a reply is required, which corresponds to the GKS deferral mode BNIL (Before Next Interaction Locally).
Sapphire and the BLIT are closer to the PERQ PNX window manager than the others, in that the virtual display abstraction is maintained, but they only store the hidden rectangles, not the entire window.
Systems such as Interlisp-D and Smalltalk are rather different, in that they only support a single address space. Communication between application and window manager is by procedure call, and can go both ways. The window manager can store pointers to application data and procedures to perform damage repair and fix ups, with no performance penalty. This makes the boundaries between application, graphics package, and window manager much more tenuous, and cannot reasonably work with a multilanguage, multiple address space system. Additionally, the entire system is tied to the particular programming language and paradigms supported. The Macintosh goes further than this in not supporting multiprocessing. MS-Windows follows the process per window model by providing each process with a virtual display, accessed through a standard set of graphics primitives. Window management follows the tiling paradigm rather than the overlapping window paradigm.
We have found that it is possible to port highly interactive programs among quite different window managers. As a result, we have reached conclusions on a number of issues:
Some issues which have not been tackled, and therefore not yet resolved are:
Finally, the main concern to be tackled is that of enabling multiwindow applications to coexist with others in a harmonious fashion. Providing equivalent facilities to the user in moving information within and between applications at a level more abstract than the display representations will require definition of new protocols. Providing the same degree of extensibility (to the user) in a graphical interface as that common in textual interfaces represents a challenging research project. The current generation of window managers appears to provide insufficient functionality to undertake these tasks, and some impose substantial restrictions.
I would like to thank my colleagues in the Common Base group and in the Informatics Division of RAL for their assistance in preparing this presentation, their work with window managers and interactive applications, and the implementation of SPY. Particular credit is owed to Mark Martin for his work in porting Spy to some of the systems discussed in this paper, and his analysis of the problems. I am grateful to William Newman and the Workshop Organizing Committee for their comments on a draft of this paper.
