The Working Group membership was:
The Working Group decided not to tackle the issues it had been given directly but first attempted to produce one or more models that captured the main points of concern at the application interface. The Architecture Working Group was responsible for the overall model but the Application Program Interface Working Group felt that it needed a model relevant to its activities as a mechanism for allowing constructive discussion.
The confusion between choice of names with the phrase user interface being used for both the programmer and operator interface led the Working Group to use the term API to stand for the Application Program Interface.
The Working Group attempted to narrow the discussion by establishing a set of basic principles that were agreed upon for window management systems. A summary of the discussion relevant to the properties given in the final report (see Chapter 16) is included below.
Nobody believed that an application would be restricted to outputting to a single window. Consequently, the application needed to specify at the API to which window output was directed. Consequently, it would not be difficult for a single window manager to control a number of display surfaces. It already had to control output going to different windows and whether they were on the same screen or not did not complicate the situation much. The SUN workstation, for example, with an attached colour display treated the two surfaces as a single entity. For simplicity, the majority view was that a window management system should control a single display space where two display surfaces with a well-defined positioning relative to each other could be regarded as a single display space.
If an application wished to set up a window on a second display space, this could be done but it would effectively be done by network communication between the window managers controlling the two display spaces.
There was general agreement that a single application should be able to output to more than one window. The view was that the application was able to output to one or more drawing spaces and the window management system was responsible for displaying parts of these drawing spaces in the display space in windows.
There was a long discussion concerning whether more than one application could draw to a single window. It clearly complicates the model if this happens. In particular. are input events in this window passed to both applications and what happens if both respond? There was a general view that drawing to a window was a capability that should only be owned by a single process at a time. However, an application consisting of a number of processes might pass the capability between them.
Windows can either be regarded as entities in their own right or have a closer attachment to an application. If an application dies. does the window continue in existence? If it continues to exist, the window manager is forced to be responsible for updating it and this leads to the need for a full bitmap to be kept by the window manager for this particular window. If windows are regarded as files, they should continue in existence after the application dies. The consensus was that windows should be regarded as having close attachment to an application. Their purpose was to provide a communications medium between the operator and the application.
At some level of abstraction, the application does not have a great deal of interest in what constitutes the window manager and what constitutes the library support for graphics etc which sits between the application and the window manager. However, the system builder has to have a clearer definition of the interfaces.
The window manager's prime functions are resource management, protection and providing an interface to the user. A major function is ensuring that application output does not stray outside the window boundary. It would be feasible for the window manager to assume that applications were correct and did not draw outside their allocated display spaces. It would also be possible for the window manager to ask the application to clip to a desired boundary. However, the view was that a primary function of the window manager is to provide protection against applications going outside the allocated resource. It was something it could not give away or neglect to do.
It was less clear what should flow across the API interface. Cases can be made for high-level graphics primitives, low-level ones or bitmaps. Each has advantages and disadvantages. For a simple 'draw line' operation, the number of possibilities is large.
Consider draw line from (x1,y1) to (x2,y2) as an output request from the application. It is assumed that the coordinates are already in the bitmap coordinates of the display. Almost certainly the application will require such a graphical command to be clipped against an application-defined clipping boundary. The window manager also requires a clip to be performed against the window boundary. Finally, the visible part of the line needs to be turned into a set of screen positions to be changed on the raster. These three functions can be done in any order and the two clips can be amalgamated. The interface between the application and window manager can be above, below or in the middle of these functions. This provides a whole range of possible alternatives some of which require added functionality in the window manager (for example, ability to clip at rectangles other than the window boundary).
The only agreement was that the window clip should be performed by the window manager.
The Working Group was presented with a set of issues to discuss. Half a day was spent in discussing these with a mode of working as follows:
The advantage of this approach is that the write-up of the issues, description, alternatives and arguments gives a good view of the depth of the discussion leaving the reader to assess the merits of the conclusion. The approach has been widely used in the graphics standards circles originating with the original discussion of the GSPC CORE proposal.
The write-up of the set of issues in the final report encapsulates the activities of the second and third periods that the Working Group met.
Presentations of the conclusions reached on issues at plenary sessions suggested that there was considerable common ground between this group and the Architecture Working Group. Instead of having two separate meetings for the fourth period, the two groups came together to attempt to come to a joint consensus on the issues or at least extend the arguments.
The combined groups identified two major areas of concern that had absorbed considerable discussion time in both groups. These were:
While the final reports of the two Working Groups were being written, Task Groups were formed to look at these two specific issues and report back. Their conclusions are given in Chapter 21 and Chapter 22.
While leaving many issues unresolved, the Application Program Interface Working Group felt it had been usefully employed discussing the issues in some level of detail and hopes its conclusions and arguments may be of use to others.
