The individual participants were asked to provide at least a one page summary of their activities of relevance to the Workshop and also to indicate their views on the major issues. From this, it was possible to establish the initial list of issues and to define the structure for three Working Groups which would most likely achieve the desired focus on the main issues.
The participants were split equally between industry and academia/government with the majority coming from the UK. Six of the participants were from the USA and Canada and provided a much needed injection of experience in building and evaluating window managers.
John Butler of Microsoft provided input from the emerging standards activities in the USA under ANSI. A particular concern of the participants in their introductory statements was the question of standardization. Was it too early?
Some of the views of the participants expressed in their introductory statements are grouped together under the headings of the three Working Groups:
Finally, the lists of issues which were drawn up as a result of considering position papers are presented. These issues are listed under the headings of the Working Groups and provided a starting point to motivate Working Group discussions.
A window manager is not a useful program in itself; it is valuable only in so far as useful and interesting applications use it. A successful window manager is one that persuades many people to write applications for it.
The most important factors in persuading people to write for a window manager are:
One way to get a successful window manager is to write a simple but adequate one with lots of applications and libraries, and then give it all away. This is the strategy that the Information Technology Centre (ITC) at Carnegie-Mellon University is trying to follow. However, one that provides many built-in features, such as the Macintosh, will make applications with easy-to-use user interfaces easier to write.
There was a general view that if progress was to be made towards establishing a methodology, it was more likely to happen at the API than elsewhere. A central issue that came from several people was the question of whether applications already in existence could run without change when put to work in the environment of a window manager. The obvious advantages are the saving in cost. However, a number of people indicated that the constraints this may put on the architecture of the system and its efficiency might be such as to make the application difficult if not impossible to use under the control of a window manager.
Assuming that the application is not asked to redraw output unless the window manager requires it, and that the covered window paradigm is assumed for the window manager, then it is almost essential that the architectural model is one where the window manager has available the current contents of all windows irrespective of whether they are visible or not.
The model as far as the application is concerned consists of a virtual terminal with a virtual screen and virtual input devices. Several virtual screens can be multiplexed on the same physical screen by the window manager. The application should be able to run unaware that a set of physical terminals is not in use.
While the above requirement was necessary, the advantages of having several separate contexts being presented in one overall context were real and it was felt that new applications could make use of the ability to transfer information between windows. This raised a number of issues as to how such interchange should take place, and at what level. Moving bitmaps may be relatively easy but, for the application, moving higher level data structures is much more important.
Existing graphics systems such as GKS [28] and PHIGS [6] provide segmentation or structuring facilities which allow graphical information to be superimposed on a single display with control of visibility of the individual segments similar in concept to window management. Are windows just segments in disguise? Should not the segmentation facility be extended to include the window concept of a rectangular region surrounding the graphical/textual information?
Nearly everybody was against rigid standardization in this area. From the industrial side, cosmetic changes in the area of the user interface are selling points widely used in industry now and are likely to continue in the future. However, it should be possible for a user to move from one system to another without major changes in the model of the interface. Using as an analogy the motor industry, users frequently wish to tailor certain parts of a car (seat position, mirrors, luggage/passenger space, etc) while most would be seriously annoyed and in danger if the car wheels turned left when the steering wheel was moved clockwise.
Assuming a multi process environment with several processes outputting to the screen and requiring input from the operator, there is a major problem in identifying which process should receive input and how input should be echoed. There is also the problem of how the window manager can help users monitor and control multiple processes running in parallel. Some systems have introduced the icon with some kind of progress indicator (e.g. sand falling in an hourglass) to help the user. Icons have been used for many distinct tasks. The view of what an icon is and how it interacts with windows is clearly a major issue. Is an icon or pop-up menu a window or not? If not, does the window manager control more than just windows?
In considering what the user and application require, it soon becomes evident that conflicts could occur between the two if the same function is available to both. For example, both the application and user may require different windows to be visible. If both windows are large and cannot both fit on the screen, which has priority?
Finally, there are a number of issues concerned with the richness and appropriateness of the tools available to the user. What is the best locator device and how many buttons should be associated with it? Does it make sense defining a user environment which works equally well with and without a locator device? Using the motor car analogy would a voice-operated car have similar constraints to one that uses a steering wheel?
The window paradigm itself also needs to be questioned. Many existing systems have followed the cluttered desk scenario while only a few seem to provide the orderly interface we are insisting on at the application interface in terms of good software engineering practice.
A major problem in any window management system is resource sharing. In particular, the display upon which windows are viewed is a resource shared between the processes with scheduling being required by the window manager itself, the individual processes and the user/operator.
While the display is the major resource to be shared, many of the functions required of a window management system will make use of RasterOp/BitBlt hardware for moving information. Such functions include picture creation, window movement and changing window attributes (inverse video etc). In each of these cases, the process which makes use of the RasterOp is a different one. Hence, RasterOp is a resource that needs to be shared between the competing processes. While RasterOp is one example, many display systems have other fast general-purpose picture-generating hardware such as colour lookup tables, geometry pipelines etc. Again, the window manager should be capable of cooperating with such hardware.
With Unix operating systems being the most widely used on most high-powered single-user systems, a major issue to resolve is how to retain the existing software investment while introducing windowing techniques as a central feature of the system environment. This involves allowing for established conventions and operations for naming, accessing and representing objects so that existing applications require no changes. At the same time, system facilities must be extended to provide support for more sophisticated styles of interaction. Windows allow several separate contexts to be presented in one overall context. From the latter viewpoint it seems natural to specify relationships and operations which apply across the separate contexts as well as within those contexts.
At some stage, the structure of the window system needs to be established. Do we just have a set of independent windows or are windows specified hierarchically with a single root window, within which all other windows lie? Child windows would then be defined relative to the origin of their parent, and might or might not extend beyond the boundary of their parent. Siblings might have relative priorities, to define which has precedence when they overlap. If such a system is defined, who is responsible for regenerating information within a window? Do we need a procedure associated with each window whose function is to regenerate it? How is this reconciled with the need to run existing applications unchanged?
Two possible models on which a simple portable window manager can be built are:
The first approach only works well if RasterOp is part of the CPU's instruction set, or if there is no hardware support for RasterOp. Unfortunately, it is very difficult to prevent hardware designers wasting resources on inappropriate RasterOp support; when they do they normally make the direct access model impossible. Further, it is impossible to provide direct access except to processes running on the workstation itself, a problem in a networked environment. Even when this model has been implemented, as with the SUN system, it has proved less popular than expected. On the other hand, a full implementation of RasterOp in hardware such as on the PERQ, can provide a great deal of added speed for graphics.
The second approach, surprisingly, works well in practice. The Bell Labs BLIT, the MIT, and the ITC systems are all examples using low-level abstractions (lines, characters, and RasterOps with pixel coordinates). The Stanford system VGTS [36], and its predecessor at Lawrence Berkeley Labs, use a higher-level abstraction, namely a structured display file.
An RPC based window manager has several major advantages:
The bandwidth limit imposed by RPC window managers is unpleasant in some cases, but they can provide competitive performance if they satisfy the following requirements:
Another, orthogonal, distinction is whether windows can change size. Forbidding size changes, as on the BLIT, is simple but probably unacceptable. Allowing windows to change size means that applications must respond to a signal, and regenerate their display. Applications like this turn out to be much easier to port.
A problem is how the window manager interacts with User Interface Management Systems. Since a window manager may have a fairly complex user interface, it is desirable that it be created by a UIMS. If applications' user interfaces are created by the same UIMS, then the various user interfaces will be consistent. A UIMS, however, may require a window manager for its operations, so there is an unfortunate circularity. Also, no current window manager has been created by a UIMS, and this may be very difficult to accomplish.
UIMSs require drawing operations which are often supplied by a graphics package such as GKS. Similarly, window managers also need a certain level of graphics operations to draw title lines and handle the covered portions of windows. How a graphics package fits in with window managers and UIMSs is another problem.
Consideration of the position papers submitted by participants resulted in three lists of issues being drawn up. The issues divided into the three categories of Application Program Interface Issues, User Interface Issues and Architecture! Hardware! Operating System Issues and they are listed below under these three headings. Participants at the Workshop split into three Working Groups covering these areas. The groups spent part of the Workshop working in parallel considering the issues relevant to their area of concern in order to try to resolve at least some of them.
