Informatics Informatics Department Methodology of Window Management

Jump To Main Content

Jump Over Banner

Home

Jump Over Left Menu

14. Issues

14.1 INTRODUCTION

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:

  1. Application Program Interface (API);
  2. User (ie Operator) Interface;
  3. Architecture.

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.

14.1.1 What is a Successful Window Manager?

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.

14.2 APPLICATION PROGRAM INTERFACE

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?

14.3 USER INTERFACE

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.

14.4 ARCHITECTURE

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?

14.4.1 Two Types of Window Manager

Two possible models on which a simple portable window manager can be built are:

  1. Direct access: client processes can be allowed to map the actual pixels into their address space, and trusted to perform the correct clipping and synchronize with other clients.
  2. Remote Procedure Call (RPC): client processes can access the display via RPCs on a server process that has access to the display. Clients therefore see some abstraction of the real display; with some difficulty this abstraction can be kept simple enough to span a wide range of devices.

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.

14.4.2 Relationship to User Interface Management Systems

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.

14.5 THE ISSUES LISTS

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.

14.5.1 Application Program Interface Issues

P1
Is the window manager or the application responsible for redrawing the contents of a window when it becomes visible?
P2
Should the user (operator) be able to change the size of a window? What effect will it have on the information in the window?
P3
What input primitives and modes should the window management system support, as presented to the application?
P4
Should an application be allowed to write directly to the screen, or should all output be via the window system? How can high performance be achieved without compromising integrity?
P5
How should positioning of windows be described, and what functions should be provided to manipulate the depth-order of windows?
P6
What graphic primitives, if any, should be supported by the window manager (ie other than direct bitmap manipulation)?
P7
How should conflicts between user and application requests be resolved, in cases such as window priority or current input destination?
P8
Should clipping to the window boundary be the responsibility of the window manager or the application? Should applications be trusted (if they so request) to remain within the window?
P9
Is grouping of windows a necessary function?
P10
Is substructuring of windows a necessary function? Should the window manager support it?
P11
Can the virtual window be larger than its portion of the screen? Is scrolling done by the window manager, or by communicating with the application?
P12
Should any title/borders associated with a window be defined by the window manager or by the application? How might the contents/appearance be specified or altered by the application?
P13
Should the window manager support colour displays and/or colour images, and if so how?
P14
Should applications be at all aware of window position, rank etc, or the existence of other applications or windows?
P15
Should input be associated with windows, subwindows, window groups, processes, or process groups?
P16
How should cut and paste between windows and applications be supported? How should the user invoke these functions, and how should the applications be informed (if at all)?
P17
Should applications be able to change window size, priority, position autonomously?

14.5.2 User Interface Issues

U1
Is the overlapping windows paradigm the correct one?
U1
Should the user (operator) be able to change the size of a window? What effect will it have on the information in the window?
U3
How should positioning of windows be described, and what functions should be provided to manipulate the depth-order of windows?
U4
How should conflicts between user and application requests be resolved, in cases such as window priority or current input destination?
U5
What set of functions operate on windows? (For example, clear, close, change depth position, move, change size, set background colour, iconize window, windowize icon.)
U6
Should the window manager provide an undo command?
U7
What styles of control structure should the window manager support or impose?
  • Reactive - user in control;
  • Active - application in control;
  • and/or mixed initiative.
U8
How should window manipulation functions be invoked? Pop-up or fixed menus; sensitive spots on borders; dedicated mouse button?
U9
How should cut and paste between windows and applications be supported? How should the user invoke these functions, and how should the applications be informed (if at all)?
U10
How should the user indicate to which window the input should be directed? How are multiple input devices dealt with?
U11
Should applications be able to change window size, priority, position autonomously?
U12
What is an icon? What attributes has it? What can the user do with it? How do icons differ from windows?
U13
What performance or functionality limitations may be imposed by the use of any special hardware, eg on- versus off-screen images, single versus multiple process access, colour table sharing, dynamic feedback (eg in remote processor )?

14.5.3 Architecture/Hardware/Operating System Issues

A1
Should the window management system be responsible for other objects on the screen such as icons, or must all objects on the screen be windows?
A2
Is the window manager or the application responsible for redrawing the contents of a window when it becomes visible?
A3
Should the window management functions provided to the operator be a subset of those provided to the application?
A4
Is grouping of windows a necessary function?
A5
Is sub structuring of windows a necessary function? Should the window manager support it?
A6
Should an application be allowed to write directly to the screen, or should all output be via the window system? How can high performance be achieved without compromising integrity?
A7
Should text windows be a special class (visibly so, to the application or user)?
A8
What graphics primitives, if any, should be supported by the window manager (ie other than direct bitmap manipulation)?
A9
Should off-screen and partially obscured windows be held in full as off-screen images?
A10
How should conflicts between user and application requests be resolved, in cases such as window priority or current input destination?
A11
Should clipping to the window boundary be the responsibility of the window manager or the application? Should applications be trusted (if they so request) to remain within the window?
A12
What set of functions operate on windows? (For example, clear, close, change depth position, move, change size, set background colour, iconize window, windowize icon.)
A13
Can the virtual window be larger than its portion of the screen? Is scrolling done by the window manager, or by communicating with the application?
A14
Should any title/borders associated with a window be defined by the window manager or by the application? How might the contents/appearance be specified or altered by the application?
A15
Where is the boundary between the graphics package and the application? For output: low level primitives versus modelling (eg PHIGS); for input: abstract input events (eg GKS CHOICE versus physical device actions). What abstraction level is provided to applications, and how is it mapped to the physical devices?
A16
Should the window manager support multiple graphics packages, multiple imaging models?
A17
What is the input model and minimum input devices required?
A18
Should fine-grained feedback be performed by the window manager? If so, (how) can interface designers specify the behaviour? How can feedback dependent on application data be achieved?
A19
Should input be associated with windows, subwindows, window groups, processes, or process groups?
A20
Should good practice (eg in display layout) be imposed at a basic level, or achieved through a higher layer implementing such policies? (The implication is that the latter might potentially be subverted.)
A21
How should simple teletype-driven applications be supported and integrated?
A22
Should sharing of windows among processes (in the sense of Unix processes) be allowed? If so, how, and to what degree?
A23
What styles of control structure should the window manager support or impose?
  • Reactive - user in control;
  • active - application in control;
  • and/or mixed initiative.
A24
How should cut and paste between windows and applications be supported? How should the user invoke these functions, and how should the applications be informed (if at all)?
A25
Should applications be able to change window size, priority, position autonomously?