Whitechapel Computer Works is a UK company founded in April 1983 which manufactures a workstation running a Unix operating system. The company is situated in the East End of London, a step or two away from Silicon Valley! This paper describes the window manager for the workstation, gives some background to the design decisions and attempts to forecast problems likely to arise in the future.
The Whitechapel MG-1's design goal was to produce a personal workstation of similar performance to existing workstations but set at a price equivalent to that of a personal computer.
Unlike most of its competitors which use the Motorola 68010, the Whitechapel MG-1 is based on the National Semiconductor 32016. The important characteristics of the design as far as the window manager is concerned are:
The MG-l currently runs a variant of the Unix 4.1BSD system (Genix) but will be moving to Berkeley 4.2 in the near future.
The first system was delivered in August 1984 and the window manager was released recently to beta-test sites.
The window manager design started in the late summer of 1984. A major concern initially was whether to use the overlapped or tiled window model. The overlap model has the advantages of giving more efficient use of the screen, and the desktop metaphor on which it is based is generally more familiar than the tiled model where the pages are continually rearranging themselves. Creating a new window or changing the size of an existing one in the tiled model implies a reorganization of the screen and this potentially causes more interference to the application.
The overlap model does demand more of the machine. As Whitechapel anticipates other people putting different window managers on the MG-l, if the MG-l is capable of supporting an overlapped window model efficiently, it will also be capable of supporting a tiled model. The main design decision was to go for an overlapped window paradigm.
The simple model of a window manager is as shown in Figure 7.1. Applications generate graphics which are displayed. If the hardware was able to support multiple contexts, no window manager would be needed at all. However, with current systems, hardware and software, the situation is not like that. A single mouse has to be multiplexed between a number of applications. Also, the operating system imposes structure on both the application and the window manager. With the firm decision to use a Unix operating system, the architecture of the software system had to fit with the basic strengths and limitations of Unix systems.
One of the major problems in the design of a window management system for a Unix operating system is that of determining the degree of functionality to embed in the kernel. Ideally, very little of the window management system would be represented in the operating system kernel; but because of the inadequate inter process communication mechanisms and susceptibility to scheduling delays under heavy load such a system would not offer fast enough feedback for a good user interface.
There is also the question of how applications will be structured. Although it appears attractive to build applications out of a large number of cooperating processes, it is likely that single processes will be used for the most part, not because this is a good way to structure programs but because it works. Unix programs are either in user space and find it hard to communicate with each other and hard to communicate with devices, or they are in the kernel in which case they are hard to program and hard to debug.
The decision was taken to split the window manager into two parts one of which was in the kernel and the other in user space. The window manager cannot be taken totally out of the kernel because time-critical tasks of window update and feedback, mouse control etc have to be carried out without a scheduling delay and, consequently, have to be in the kernel. On the other hand, one cannot have the application program having to do all graphics updates via an IPC mechanism.
That implies that the part of the window manager that actually deals with graphics should go into the kernel in some sense and you leave outside the parts of the window manager that do user interfacing. There is no question of embedding the user interface into the kernel as that would be disastrous. The problem that arises is what is the appropriate level of the division between graphics operations inside the kernel and window operations outside.
The application, of course, just sees a single collection of functions that can be called and is unaware of the split. The revised diagram of the window manager is shown in Figure 7.2.
The Whitechapel window manager has two main objects that are manipulated, panels and windows. The application deals with panels which have no user interface properties. The user deals with windows which are much more of interest to the user than the application. The kernel resident part of the window manager only knows about panels. All the window management functions are in a user process (window manager).
A panel is a rectangular area which is a viewport onto a client or application bitmap. Applications output graphical and textual information to panels. A major design decision is at what level does information pass from the application to the part of the window manager implemented in the kernel and responsible for updating the panels? Because the kernel is difficult to change and it is envisaged that applications run in a single system, the decision was taken that the interface should be at the bitmap level.
Applications call graphics primitives in libraries which maintain a bitmap copy of the image that they are displaying. The information passed from the application to the kernel is either the complete bitmap (when the panel is created) or a subrectangle when part of the panel needs updating. Incidentally, a paper study has shown that this system can be mapped on to hardware which uses display lists and where there is no access to bitmaps, provided clipping can be done efficiently.
Panels have a position and priority on the display so panels give you a division of the screen into a set of possibly overlapping rectangles. Panels are organized in a hierarchy with each panel having only one parent but it may have several child panels. The positions of children's panels are relative to the parent. Consequently, it is possible to build a family of panels all descended from a single parent which will move around the screen as the parent moves.
Support for pop-up menus is achieved by creating a new child panel containing the pop-up menu. The pop-up menu is deleted just by deleting the child panel from the hierarchy.
The part of the window manager in the kernel manages panels, while the part running as a user process manages windows. Messages to the window manager currently use an IPC mechanism which is actually a pseudo TTY in order to provide some portability between Berkeley 4.1 and 4.2.
The window manager creates and manipulates windows for the user. The window consists of a set of panels some of which are provided for the application to use while others (borders and title) are created by the window manager. A typical window is shown in Figure 7.3.
The window manager reserves the corners and title bar for its own use, only allowing the application to change the text in the title bar. The edges of the window are owned by the application with library routines being provided to allow functions such as scrolling, splitting, changing size etc.
The window manager organizes the desktop; window creation and destruction (by explicit Unix commands) and provides corner controls for reorganizing the desktop (move, resize etc). The window manager itself does not have any menus nor does it predefine any button use. The window manager regards all buttons on the mouse as equivalent. This it is believed will cause the minimum interference with any application.
In the kernel, the panel manager is responsible for handling the hierarchy of panels which are displayed as a set of overlapping rectangular areas. The main strategy has been not to expect too much from the application. Consequently, all redrawing of windows that become uncovered is the responsibility of the panel manager. The view was that it was unreasonable to send a signal to the application that certain parts of the display need to be redrawn.
To accomplish the redrawing, the panel manager has off-screen in memory the complete bitmap of each panel. The experience so far is that performance implications are reasonable.
With the hardware support for cursor changing, it is sensible for all cursor changing to be done in the kernel. Effectively, the window manager and application tell the panel manager which cursor should be displayed in each region of the display. Using the hardware cursor support and the cache memory, it is possible to allow an arbitrary number of regions on the screen with different cursor pictures associated with them.
The kernel also provides some feedback for functions such as wire frames and rubber bands. Other functions could be added but the aim will be to keep the number of options as low as is reasonable.
We see two main areas of interest in the future, colour and low-cost laser printers.
In terms of colour, the major problems are the diversity of requirements and the need to retain compatibility with the existing monochrome system. A major problem is how you handle colour tables when the workstations are likely to have one or a few colour tables while the applications are likely to require a different colour table per window. The problem is similar to the one that arises with cursor pictures.
The second area is the ability to output to laser printers. It is clear that within a short timeframe the cost of laser printers in the UK will be down to less than £1500 per workstation (possibly $500 in the USA) and it is beginning to be possible to consider a laser printer per workstation. The major problems are the cost of the interface and the resolution of the laser printer which exceeds that of the workstation display. This implies that output to the laser printer must derive from closer to the application than the bitmap image which is currently our interface between the application and the Unix kernel panel manager. This leads to the need for defining a higher level interface. Until the talk by James Gosling, my view had been that PostScript seemed impossibly complex actually to do real-time image updates. I would like to be proved wrong!
