Contact us Heritage collections Image license terms
HOME ACL ACD C&A INF SE ENG Alvey Transputers Literature
Further reading □ Overview □ Preface □ Acknowledgements □ Participants □ Contents □ 1. Introduction □ 2. Unix □ 3. Comparison □ 4. Ten Years □ 5. SunDew □ 6. Issues □ 7. Modular □ 8. Standards □ 9. Standards view □ 10. Structure □ 11. Partitioning □ 12. Low-Cost □ 13. Gosling □ 14. Issues □ 15. API WG □ 16. API WG □ 17. UI WG □ 18. UI WG □ 19. Arch WG □ 20. Arch WG □ 21. API Task Group □ 22. Structure Task Group □ 23. Future □ 24. Bibliography □ 25. Acronyms
CCD CISD Harwell Archives Contact us Heritage archives Image license terms

Search

   
⟶ Informatics ⟶ Literature ⟶ Books ⟶ Window Management
⟶ Informatics ⟶ Literature ⟶ Books ⟶ Window Management
ACL ACD C&A INF CCD CISD Archives
Further reading ⇓

□ Overview □ Preface □ Acknowledgements □ Participants □ Contents □ 1. Introduction □ 2. Unix □ 3. Comparison □ 4. Ten Years □ 5. SunDew □ 6. Issues □ 7. Modular □ 8. Standards □ 9. Standards view □ 10. Structure □ 11. Partitioning □ 12. Low-Cost □ 13. Gosling □ 14. Issues □ 15. API WG □ 16. API WG □ 17. UI WG □ 18. UI WG □ 19. Arch WG □ 20. Arch WG □ 21. API Task Group □ 22. Structure Task Group □ 23. Future □ 24. Bibliography □ 25. Acronyms

16. Application Program Interface Working Group Final Report

16.1 DEFINITIONS

A window is a region on a display surface whose size, position, and display priority relative to other windows may be changed at will by the operator. Different windows may vary in their appearance: presence of title bars, border style, kind of scroll bars, etc.

Several windows may appear on a display surface. Conceptually speaking, a display surface may extend across several physical screens.

A Window Management System (WMS) is a system service that provides for the creation, deletion, and modification of windows. The WMS allocates scarce resources (represented by on-screen real estate, entries in a colour map, use of mouse and keyboard input devices) among contending applications.

16.2 PROPERTIES OF A WINDOW MANAGEMENT SYSTEM

A WMS has the following characteristics:

  1. A WMS controls the resources associated with only one display space.
  2. A WMS manages a set of cartesian coordinate systems (drawing spaces) from one or more applications concurrently. A subset (possibly all) of each drawing space is presented in a single window.
  3. Only one application at a time can write into a drawing space (and, consequently, to each window). The application is said to own the drawing space and the associated window.
  4. A single application can own several windows concurrently.
  5. A display space and its associated window does not exist without being attached to an application. Consequently, windows go out of existence when the application that owns them goes out of existence.
  6. An application may transfer ownership of a window to another application.
  7. The WMS is responsible for ensuring that the owner application does not draw outside the window boundary.

16.3 CONTROLLING THE WINDOW MANAGEMENT SYSTEM

There are two methods by which an operator can control the WMS: indirectly via an application (the application program interface, API in Figure 16.1) and directly via a special layout task (the operator interface, OI in Figure 16.1).

Application 1 (AP1) Application 2 (AP2) Layout Task API API OI WMS Input Devices Display Surface Operator

Figure 16.1

Some of the functions expected to be included in the API are:

  1. creating and destroying windows;
  2. redrawing images in windows;
  3. providing titles for windows;
  4. requesting the allocation of colour table entries;
  5. requesting a sampling input from the mouse, keyboard, or function button.

Some of the functions expected to be included in the OI are:

  1. resizing and repositioning a window;
  2. changing a window display priority;
  3. reassigning an input device from one application to another.

The exact relationship between the API and the OI (in terms of the functions supported) is not yet agreed. Possibilities include:

  1. the functionalities are identical;
  2. the functionality of OI is a subset of API;
  3. the functionality of API is a subset of OI;
  4. the API and OI functionalities are totally disjoint;
  5. there is some overlap of functionality, but each has some functionality of its own.

16.4 MODELS OF THE APPLICATION - WINDOW MANAGER INTERFACE

A major problem in the resolving of issues in the Application Program Interface was getting a clear idea of the model and level of the interface. To aid discussion, the following three models were introduced.

In Model A (see Figure 16.2), the assumption is that existing packages for graphical (GR) and text (TTY) output are used by the applications, and interface to the window manager (WM) at a relatively low level. This could be in terms of a bitmap but might also include some standard primitives. Existing applications would effectively be making changes at the device driver level in order to run in a window management environment. An example of a window manager along these lines is the one on the Whitechapel MG-l. The major attraction is that little change is required to the application. On the other hand, because the interface to the window manager is at a low level, it is likely to be less device independent than other models. As the window manager is responsible for resource protection, the window manager will need to check and possibly clip output presented to it by the GR/TTY modules.

AP1 AP2 GR1 TTY1 GR2 TTY2 WM Display

Figure 16.2 Model A

AP1 AP2 GR TTY1 TTY2 WM Display

Figure 16.3 Model B

AP1 AP2 GR1 TTY1 WM GR2 TTY2 S H A R E D Display

Figure 16.4

In Model B (see Figure 16.3), the window manager interfaces to the application at a high level and has a full range of Graphics/Text Primitives as part of it. An example of the protocol level between the application and window manager would be something of the same order of richness as PostScript, extended for input.

Each application would need to replace its existing interface to the graphics system associated with it by one to the facilities provided by the window manager. The advantage of this approach is a higher level of device independence and also gives the window manager the ability to use special hardware functionality if and when it becomes available.

In Model C (see Figure 16.4), the existing GR and TTY subsystems are integrated with the window manager so that the reconstructed graphics system etc is forced to provide the necessary protection to ensure that it does not write outside a window.

The advantage of this approach is that the functionality of the graphics system for clipping etc can be used by the window manager under its control to ensure the necessary resource protection.

To a large extent Model C is a compromise between the first two models.

16.5 ISSUES

These are listed on the following pages. A summary of the issue titles, their origins and the Working Group's recommendation on each is contained in the table following.

No. Issue Derivation Recommendation
1 Can an application running under the window manager turn off the window manager's protection mechanism? P4 reworded No
2 Should the window manager notify an application when resources allocated to it change? P14 part 1 Application can ask to be notified about change in specific resources.
3 Should an application be aware of resources allocated to it? P14 part 2 Yes
4 Should an application be aware of resources allocated to other applications? P14 part 3 No
5 How should cut and paste be supported between applications under the control of the window manager? P16 NONE
6 Should the operator be able to change the size of a window, change colour table etc continuously? P2 NONE
7 If both application and operator can change size, colour tables etc and thus use of resources over time, how are conflicting requests for changes handled? P7 NONE
8 Can the application change the listener? P7 addition Majority for YES
9 Should there be the capability for a separate listener for each input device? P7 part Yes
10 Should applications (other than the layout manager) be able to change window size, position, priority etc continuously? P17 NONE
11 Who is responsible for drawing (part or all of) the contents of a window when it becomes uncovered? P1 Application can volunteer to redraw - default is window manager.
12 Who is responsible for clipping to the window boundary (in later terminology, the panel boundary)? P8 Window manager
13 How is scrolling done? P11 part NONE
14 Should the virtual window (the off-screen window image, or picture) be the same size as its portion of the screen? P11 part No conditionally
15 Should the application program interface for the window manager provide support for substructuring of windows? P10 Yes
16 How is input handled in the window manager? P3 NONE
17 At what level should the interface between the application and window manager exist? P1 NONE
Task Group formed
Issue 1:
Can an application running under the window manager turn off the window manager's protection scheme?
Description:
The issue was originally written as to whether an application should be allowed to write directly to the screen. The issue was rewritten to avoid assumptions about the method by which the screen is accessed to make clear that mutual protection of windows by enforcement of clipping is a major role of the window manager.
Alternatives:
  1. Yes
  2. No
  3. Only under certain circumstances.
Arguments:
  1. CON 1,3: MS-DOS illustrates that in an environment where there is a standard way of doing something and a faster non-standard one. the non-standard way will be used all the time irrespective of the need for speed.
  2. CON 1,3: Would allow applications a closer knowledge of the hardware and could lead to certain displays not being suitable for window management graphics, for example, no memory map.
  3. CON 1: Forbids use of server-style window managers.
  4. CON 2: The graphics system already provides a clip at the workstation boundary. If this is the same as the window boundary, an unnecessary clip takes place. If this is smaller than the window boundary either the window manager must be capable of clipping to an area smaller than the window boundary or clipping will take place twice when only once is required.
  5. CON 2: Assumes a way of working that may be applicable today but possibly not in the future. A default method of being non-standard could be useful.
  6. CON 2: Overhead will almost certainly mean that some applications will not be able to run smoothly and effectively in a window management environment. An application that is well-behaved should be able to reduce window management overhead to a minimum.
  7. CON 2, PRO 3: Necessary protection of window manager could be achieved by saving and restoring the world so that allowing application access to screen does not necessarily lose all protection.
Recommendation:
Alt 2 (unanimous).
Issue 2:
Should the window manager notify an application when resources allocated to it change?
Description:
The operator can perform a number of operations on a window which could potentially be of value to the application - for example, the position of the window on the screen. Other changes, such as resizing the window, can give poor visual results unless the application redraws the window.
Alternatives:
  1. Always
  2. Never
  3. Application can ask to be notified about changes in specific resources.
  4. Window manager could decide which changes need to be notified.
  5. Resources are never changed.
Arguments:
  1. PRO 3: Application may not be exploiting all the allocated resources and may not be interested in certain changes. For example, may be happy to run however much of CPU is allocated. May be able to run whatever the window size.
  2. CON 2: Impossible to write programs that use resources effectively. For example, an editor needs to reformat text when window has changed in size.
  3. PRO 5: Operator should not be allowed to change resources required by application. It could leave the application with insufficient space or resource to work at all.
  4. CON 2: The role of the window manager is to allocate resources to competing demands. This allocation can be static through the lifetime of an application, or it may change. Forbidding change is too restrictive.
  5. PRO 3: While some applications may be able to use information passed to them, others may not. It may not even be possible for the window manager to send information to the application. Thus both (I) and (2) are too restrictive.
  6. PRO 4: Given enough intelligence, window manager could perhaps separate critical changes from others.
  7. CON 3: A filter of this type complicates the interface.
Recommendation:
Alt 3 (unanimous).
Issue 3:
Should an application be aware of resources allocated to it?
Description:
This is a general statement concerning all resources. These could include current size of window, amount visible, how much CPU time allocated to this process, whether there is off-screen memory associated with the window etc. It is assumed that the operator and/or window manager can change the original allocation of resource in some way.
Alternatives:
  1. Yes
  2. No
Arguments:
  1. PRO 1: An application's request for resources cannot be guaranteed to be fulfilled as the window manager is a resource allocator. Consequently, there is a need for the application to be able to enquire whether the resources given are sufficient for it to run and the allocation could affect its method of running.
  2. PRO 2: Application should be unaware that it is running under a window manager.
  3. PRO 2: Application may not be able to deal with resource changes.
  4. PRO 1: Window manager methodology allows operator to change window size. Application must have the ability to find out whether change has taken place.
  5. PRO 1: Colour table may be the resource and application may not be able to run if it is not set to its requirements.
  6. PRO 1: Windows could be marked as changeable by operator so application could be helped.
Recommendation:
Alt 1 (unanimous).
Issue 4:
Should an application be aware of resources allocated to other applications?
Description:
An application may need to know what resources are allocated to other applications running at the same time in order to decide how to run. For example, CPU time may need to be scheduled between several processes.
Alternatives:
  1. Yes
  2. No
  3. Privileged applications only..
Arguments:
  1. PRO 2: Too complex an interface otherwise.
  2. PRO 1: Could be necessary in some models of cut and paste.
  3. PRO 2: Cut and paste should be done as a negotiation between applications, with each enquiring of its own resources; otherwise security could be lost.
  4. PRO 1,3: Unless at least one application has the ability to enquire of all resources, it is impossible to define an application-level program which tidies up the screen.
  5. CON 2: Cannot write layout process or clear screen.
  6. PRO 3: If we distinguish between the layout application and normal applications, the latter should be protected and mutually unaware - the former should be all powerful.
Recommendation:
Alt 2 (unanimous).
Issue 5:
How should cut and paste be supported between applications under the control of the window manager?
Description:
In window managers such as the Macintosh it is possible for an application to take part of the information in another window and use it. The information passed in this way could either be the bitmap on the screen or the data structure that produced it. Both need to be allowed for.
Alternatives:
  1. Not supported at all.
  2. Window manager maintains an uninterpreted cut buffer. Applications can read and write bytes to the buffer. Cut and paste are thus asynchronous.
  3. Window manager arranges for a connection between the cut application and the paste application (cf: a pipe). Cut and paste are thus synchronous.
  4. One level of window manager supports cut and paste via alternatives (2) and (3), a lower level does not.
  5. Window manager interprets the contents of the cut buffer for applications.
Arguments:
  1. PRO 2,5: Applications using a server-style window manager on a network may not be able to use a common file name space to provide cut and paste outside the window manager.
  2. PRO 1: Common practice - few existing window managers support cut and paste.
  3. PRO 4: While seeing the attraction of cut and paste, it is clearly not always necessary as existing systems do not use it. Consequently, a level option would allow a choice of implementation.
  4. PRO 2, CON 3: Simpler and requires less of the operating system.
Recommendation:
None - more support for Alt 2 than others.
Issue 6:
Should the operator be able to change the size of a window, change colour table etc continuously?
Description:
Changing the size of a window may change the amount of resources needed by an application. Allowing the operator to change size, colour table etc at will, implies that applications are not guaranteed access to resources which are stable over time. This is substantially different from file or memory resources which, once allocated, are secure.
Alternatives:
  1. Yes
  2. No
  3. Some windows allow such change, specified at creation.
  4. Application can specify whether it allows changes.
Arguments:
  1. PRO 3: Windows such as pop-up menus should not have their size changed by operators while others should allow it.
  2. PRO 1: The application can never get a guarantee of the resources it requests. So allowing the operator to change it does not change the situation. For example, two applications cannot have the colour tables set to their requirements if they are incompatible. The memory required for a new window may not be available etc.
Recommendation:
No support for Alt 2. No agreement for any of the others.
Issue 7:
If both application and operator can change size, colour table use, etc, and thus use of resources over time, how are conflicting requests for changes handled?
Description:
The dynamic reallocation of resources under application or operator control may be desirable for at least some windows. The API may be written so that it semantically excludes possibilities of conflict ( ie, either operator or application may cause reallocation, but not both), or else it may permit conflicts.
Alternatives:
  1. Application requests override operator's.
  2. Operator requests override application's.
  3. Either (1) or (2), specified for each window.
  4. Either (1) or (2), specified for each window/attribute pair.
  5. Semantically excluded, rendering the issue moot.
Arguments:
  1. PRO 5, CON 3, 4: Only sensible solution to avoid conflicts; (3) and (4) too complicated.
  2. CON 2: Probably outlaws pop-up menus in some systems.
Recommendation:
Only alternatives getting support were Alt 2 and Alt 5.
Issue 8:
Can the application change the listener?
Description:
There is one window that currently receives input from the keyboard, called the listener. Some window systems allow only the user to change the listener. Applications may also have varying degrees of control over the attachment of input devices. Note that application here excludes that part of the window system providing operator control.
Alternatives:
  1. Application can request listener change.
  2. Application cannot change listener.
  3. Application can change listener but only to another window also owned by it. Effectively if application already has listener, it is allowed to change it to another of its windows.
Arguments:
  1. PRO 2: Changing of the listener by the application may conflict with the desires of the operator. It could also affect the quality of the user interface if misused. (However, badly behaved programs would be avoided by the user!)
  2. PRO 1: Cases exist where it could be useful - a lock-up application to make keyboard/mouse unusable until released. Command and Control systems may have override requirements.
  3. PRO 2: A block by the operator is necessary: ie the applications can only request listener changes.
  4. PRO 2: Application could run wild.
  5. CON 1,2,3: It might be reasonable for the application to have the capability of giving away a listener rather than taking it. In that situation, the listener would become available for other applications to ask for.
  6. PRO 3: If we can transfer other capabilities, we can transfer listeners.
  7. PRO 2, CON 1: You could have an application on a network which kills windows on all machines. You need some protection.
  8. PRO 1: If a user is editing and running a debugger at the same time, it would be useful for the listener to move automatically to the debugger on a break point.
  9. CON 1 : You might not want it to happen even if the debugger felt you should!
  10. PRO 3: In this editor/debugger scenario, the two programs need to be linked in some way so that the listener returns to the editor at the correct position.
Recommendation:
Majority for Alt 1 but not unanimous.
Issue 9:
Should there be the capability for a separate listener for each input device?
Description:
Some window managers attach all the input devices to the same listener window, with variations for communication with the window system itself. It is possible for each input device to be attached to a listener independently of all other devices.
Alternatives:
  1. Yes
  2. Only one listener window.
  3. Keyboard and the rest - two listeners.
Arguments:
  1. PRO I: Even more generality needed, you might want to input to several windows at the same time by one device.
  2. PRO 1: How else can you handle voice input sensibly.
  3. PRO 1: It is important that we can specify that different applications have control of different devices and keep them. For example, only one application might be using a digitizer and it would be crazy for it to be transferred to another window each time the operator stopped to do something else.
  4. PRO 1: Applications can be envisaged which would require typing in one window while using the mouse in another.
Recommendation:
Alt 1 (unanimous).
Issue 10:
Should applications (other than the layout manager) be able to change window size, position, priority etc continuously?
Description:
It is usual to allow control of resources to be given to the operator. The query is whether such control should also be given to the application.
Alternatives:
  1. Yes
  2. No
  3. Some windows - specified at creation time.
Arguments:
  1. PRO 1: Applications are able to change the amount of file and memory space required, so why not these other resources.
  2. CON 1: These resources are different from those given in (a) as the operator using the application is aware of the changes.
  3. PRO 2: The "principle of least surprise" and the principle of "the user is king" suggest that applications not be given the same authority over windows.
Recommendation:
Some feeling towards Alt 2.
Issue 11:
Who is responsible for drawing (part or all of) the contents of a window when it becomes uncovered?
Description:
When the operator moves a window or moves one to the bottom, the parts of windows that become visible need to be redrawn. Either the window manager or the application can be responsible for the redrawing. It is even possible that the window that was doing the hiding should do the redrawing. Much depends on the interface between the application and window manager.
Alternatives:
  1. Only window manager via virtual bitmap.
  2. Only application.
  3. Application can volunteer to redraw - default is window manager.
Arguments:
  1. PRO 1,3: It is in poor taste to require application to redraw.
  2. PRO 3: In some cases application may have faster or more compact representation of the image and it is in the application's interest for it to be responsible for the redraw.
  3. PRO 3: Fits in with other issues where it is sensible for application to be aware of the resources allocated to it.
  4. PRO 3,1, CON 2: Window manager should ask the application to redraw as infrequently as possible.
  5. PRO 2,3: Application may be easier placed to redraw only a small rectangle of the window.
  6. CON 2,3: In some window managers, it is easy for window manager to redraw and very difficult for application.
  7. CON 2: Do not like the model where application keeps receiving requests from window manager to repair windows.
  8. CON 2: Application may not be able to redraw. Perhaps it is a storage tube output graphics system or viewing previously-generated output. It may require a system between the application and window manager to save the current contents of the window in which case it might as well be the window manager.
  9. CON 2: Even if the application redraws the window, there is a need for the window manager to do the necessary clipping and this is not to the original window boundary. Window manager might not have this capability. Easier if application always redraws whole picture but there are then performance issues.
  10. PRO 2: If a window can be created that is not on top, the application rather than the window manager should do the clipping.
  11. PRO 3: The split of responsibility should be 99% window manager and 1 % application.
  12. CON 3: Application may say it will take care of screen and then do nothing. Result is screen becomes a mess (rebuttal: is this a bad or bug-ridden program?).
  13. PRO 1,3: Memory is getting so cheap that worrying about window manager having a virtual bitmap is not sensible.
  14. CON 1: For a 2048 x 2048 x 24 colour system with many windows, it will always be a large overhead.
Recommendation:
Alt 3 (unanimous).
Issue 12:
Who is responsible for clipping to the window boundary (in later terminology, the panel boundary)?
Description:
The role of the window manager is to control the layout of information on the display. Given the right hardware it might be sensible for it to leave the clipping to the application. Also, if it cannot do clipping efficiently and the application can by use of specialized hardware at the application level, it may be necessary to trust applications to behave as the window manager instructs but it should probably be avoided if possible. The main issue is whether the role of the window manager is to ensure mutual protection for applications.
Alternatives:
  1. Window manager.
  2. Application.
  3. Shared.
Arguments:
  1. CON 2,3: If we are going to have integrity, application must not be allowed under any circumstances to draw outside the bounds of its window.
  2. CON 1: Not possible always in practice to implement this way.
Recommendation:
Alt 1 (unanimous).
Issue 13:
How is scrolling done?
Description:
One of the principal uses of a window is to examine textual or graphical material which extends beyond the boundaries of the current window. Support is often provided in a window management system to allow the operator or application to scroll text within the window or to pan around a larger graphical picture. If there was a much larger bitmap kept by the window manager, it would be possible for many of these operations to be performed by the window manager without needing the application to be involved.
Alternatives:
  1. Scrolling is not supported by the window manager.
  2. Scrolling is completely handled by the window manager.
  3. The window manager provides a scroll indicator specifying where display should begin, application does the actual repainting.
  4. The window manager only supports scrolling across a display space which is larger than its image on the screen but finite.
Arguments:
  1. PRO 3: There are two problems, what bits need repainting and who paints them. It is clear that the window manager specifies the first. The second may be better done by the application.
  2. PRO 2,3: Eventually the application has to do scrolling as the window manager cannot keep an infinite buffer. Having it kept partly by the window manager complicates the model. Even if the window manager keeps a buffer it should be regarded as an efficiency issue with the model having the application doing it.
  3. PRO 1: The window manager functions should be kept to a minimum and this is not a necessity. Why stop at panning and scrolling. If you are going to do scrolling, it probably opens the door for a whole set of other functions.
  4. PRO 2: This can be achieved by the application passing to the window manager a procedure which does the necessary redrawing.
  5. PRO 3: The window manager has to provide the facility for interaction for scrolling, scroll bars etc. The application needs to get involved as the unit of scroll may be application dependent. The application may insist that text gets scrolled a line at a time.
  6. CON 4: Too complex a model.
  7. CON 1: Many existing window managers provide this facility via explicit operator tools and they are well used.
  8. CON 2: Not possible unless the application can pass procedures to the window manager to achieve the scroll.
  9. CON 3: Depending on the input model, it may not be possible to synchronize the request to repaint and the actual repaint. May always land up out of step.
Recommendation:
None.
Issue 14:
Should the virtual window (the off-screen window image, or picture) be the same size as its portion of the screen?
Description:
Some window systems make these the same size. Others allow the virtual window to be larger, and the window area may be panned over the picture without further application intervention. It was decided that this was a separate issue from allowing window manager to be responsible for scrolling as scrolling could be achieved by an exported procedure from the application to the window manager.
Alternatives:
  1. Yes, should be the same size.
  2. No, may be different size.
  3. No, but the window manager should be able to say it does not have the resources to keep a complete virtual window of the screen area.
Arguments:
  1. PRO 1: The window system is simpler if they are the same size.
  2. PRO 2: Some applications (VLSI design) may require panning over the image faster than or decoupled from the generation of the image by the application.
  3. PRO 3: There is a resource allocation problem. The window system may not, or some may never, have the additional storage for the virtual window.
  4. CON 2: Requires additional operator functionality and, if provided by window manager, may not be compatible with other application interactions.
  5. CON 1,2: Both imply a virtual bitmap. The off-screen image could be a display file.
  6. PRO 2,3: Existing window managers already support larger virtual windows.
  7. PRO 2,3: System with large memory should be able to use it for this purpose.
  8. PRO 1: Dumb applications not capable of performing pan and scroll, could use an intermediate system to deal with it. There is no good reason for insisting that it is part of the window manager with an overhead for all systems.
Recommendation:
Alt 3 - not unanimous.
Issue 15:
Should the application program interface for the window manager provide support for substructuring of windows?
Description:
Windows are often constructed with boundaries which are separate areas having different properties. The application could be made aware of these and treat the set of subareas as a window with perhaps different control of each. Alternatively, the application could be only aware of the drawing area with the window manager having responsibility for the boundary.
Sometimes the application would like to subdivide the drawing area in a way similar to the functions provided by the window manager. A sub structuring facility would allow this.
Alternatives:
  1. Yes - substructuring is provided.
  2. No - sub structuring is not provided.
  3. Yes - but only special, predefined substructures are provided.
Arguments:
  1. PRO 1: It may be necessary for performance reasons that substructuring is provided and accessible to application.
  2. CON 1: Substructuring provided may not suit the application in which case it still has to be built on top.
  3. PRO 1: Windows are often constructed with special dedicated areas which have specific semantics. Such areas can be created by software above the window manager, but providing support at the window manager level may prevent needless duplication if such services are often used by the application.
  4. PRO 1: If window manager provides substructuring, windows wi11 reflect this. Common implementation techniques and access to them will provide a more standard user and application interface.
  5. CON 1,2,3: The alternatives need to be more clearly expressed before the arguments for and against can be established.
  6. PRO 1,3: Some systems make heavy use of pop-up menus where the menu is fixed in place relative to the window it is associated with. It is effectively a substructure of the window even though it may have a separate boundary. As it moves when the window moves, it has to be supported by a substructure facility.
  7. PRO 1.3: A number of entities associated with windows have similar properties to windows in terms of screen management (pop-up menus) but are not true windows in the application sense (do not have titles, borders, etc). These are best handled as substructures.
  8. PRO 1,3: Everybody is agreed that the application is free to draw in the main part of a window. An issue is whether the window manager provides support to manipulate borders and subregions or does the window manager send signals to the application program. If the latter, it is likely that the application will need to be aware of the substructuring.
  9. PRO 1,3: If different mouse events are required in different subregions of a window, it is necessary for the application to have access to a substructuring facility.
  10. PRO 1,3: Some systems use a hierarchy of windows where the screen is the main window, the application windows are substructures of it and so on. In this model, sub structuring is an intrinsic part and going to another level of substructuring is no problem.
  11. CON 1,3: If substructures get too complex, have different boundaries and have all the functions of windows, they become multiple windows. The only property different from an application having multiple windows may be whether they can be moved independently. A user can push a window away but not a substructure.
Recommendation:
Application Program Interface Working Group had no consensus but the combined Application/Architecture Working Group meeting came out strongly in favour of some kind of substructuring.
Issue 16:
How is input handled in the window manager?
Description:
The existing window managers do not have the richness of control provided by GKS input where all devices can operate in REQUEST, SAMPLE and EVENT modes. Some window managers only support one mode or leave the application to do some of the work. The GKS input model does not address the problems specific to multiwindow environments where different windows may want to operate the same device in different modes. Also the window manager itself makes use of the input devices.
The Computer Graphics Interface (CGI) standard is at a lower level than GKS and should be the protocol used between a device and a GKS workstation. It may well be sensible to model the window management input on the CGI model.
Alternatives:
  1. The GKS input model is provided.
  2. The CGI input model is provided.
  3. Something else applicable specifically to the window manager environment.
Arguments:
  1. PRO 3: It is feasible that you may wish to input to several windows at the same time and neither of the models currently existing support this.
  2. PRO l: Applications are using this and so the window manager needs to support it.
  3. CON 3: We have one too many input models already.
Recommendation:
None.
Issue 17:
At what level should the interface between the application and window manager exist?
Description:
The interface between the application and the window manager can be at various levels. Many existing window managers have the interface at the bitmap level with the application producing changes to bits in a virtual window. Others have a higher level interface where graphics functions are provided by the window manager for the application to use. There is also the possibility of the application sending procedures to the window manager to produce the output.
Alternatives:
  1. At the bitmap.
  2. Window manager has low level graphics functionality only - draw line say.
  3. All of GKS NDC functionality in window manager.
  4. Interface is via procedure passing.
Arguments:
  1. CON 1,2,3,4: As long as the functionality provided to the application by the graphics system is the same, it is irrelevant which parts are in the window manager.
  2. PRO 3,4: The higher the interface level, the more device independent it will be.
  3. PRO 1: As all displays to first order have virtual bitmaps, this is the best way of achieving device independence.
  4. PRO 4: Appears to be the only way good flexible control of input by the application can be achieved.
  5. PRO 3: The higher the level of the interface, the more likelihood that the window manager functions can be taken over by hardware.
Recommendation:
A special Task Group should look at the problem (see Chapter 21).

16.6 PORTABILITY

16.6.1 A Portable Window Manager?

In general, the model of a bitmap monochrome display as an array of bits in memory with no other attributes and no special hardware to manipulate it results in software that is portable across a wide range of existing workstations. In some cases, this bit array may have to be maintained as a shadow of the screen, with modified regions or the whole screen moved to the real display memory at intervals.

Exploiting RasterOp hardware leads to another possible interface at which portability might be achieved: that of a 2D array of pixels with the 16 binary RasterOp functions. The need to apply them to process virtual address space reduces the usefulness of much existing hardware.

16.6.2 A Portable Window Manager for Unix Systems?

  1. Should be a user process: kernel source code may not be available to port a window manager requiring kernel support. (Caveat: beware hardware which forbids user access to the display.)
  2. Should assume that the display is an array of bits in memory with no hardware support, that there is no cursor support, and that the kernel does not interpret mouse input.
  3. Should be prepared to exploit RasterOp hardware, cursor support and autonomous mouse tracking.

The CMU and MIT (X) window managers are of this type.

16.6.3 Portable Window Applications for Unix Systems?

Porting the window manager may not be necessary. If applications are written using a simple subset of window manager calls they can probably be moved with little effort. Example subset includes:

This was the objective of the design of the CMU window manager described in Chapter 13.

16.7 FUTURE WORK

The Working Group identified a number of areas where future work was required before any conclusions could be reached. Other areas were insufficiently explored to achieve any conclusion. This list contains items of both types and also indicates some areas of future work which would be worthwhile in order to resolve some issues or gain experience of conclusions reached.

  1. Input model: insufficient time meant that we were unclear whether a satisfactory input model could be obtained at this point in time. Issues arose over event queues (one or many?), type ahead/mouse ahead (are they allowed and if so how do you achieve correct ordering where necessary?). How is the listener defined and are there many? What are the logical input devices and their modes of operation?
  2. High level application interface: we have experience of window managers based on low level interfaces. Experience with one based on a high level interface with good control of feedback to the operator is an area where future work would be fruitful. Can a portable window management scheme be devised?
  3. Structured windows: there was general agreement that some subset structuring facility was desirable and this might be the route to incorporate pop-up menus and icons into the general model. More work needs to be done in defining such a model and testing it.
  4. Window hierarchy: should hierarchies greater than level 2 be supported? For what reasons is such a model desirable?
  5. Cut and paste: there was general agreement that a window management system should provide cut and paste facilities between applications. There was no consensus as to how this would be achieved or how cut and paste above the bit level would be achieved.
  6. Sneak paths: it was unclear to this Working Group whether sneak paths were harmful or should be fully integrated into the model. How do you provide them if conceptually they are not there?
  7. Window classification: many issues can be resolved by defining classes of windows which have restricted behaviour (for example, menus and icons etc). Is there a need to introduce window attributes as a method of simplifying the model? Is this a mechanism for tailoring systems to individual users or classes of users (novice versus expert)?
  8. Operator/application conflicts: if both application and operator are allowed a certain function, how do you avoid conflicts?
  9. Icons: icons are used for many purposes. There is still no model of how these fit into the overall window management system.
  10. Level of portable window manager: a number of principles have had broad agreement at the Workshop. Is it possible to produce a low level portable window manager?
  11. Operator/application functionality: should they be identical, a subset of each other or two overlapping sets? If the last possibility, what is in the overlap set?
⇑ Top of page
© Chilton Computing and UKRI Science and Technology Facilities Council webmaster@chilton-computing.org.uk
Our thanks to UKRI Science and Technology Facilities Council for hosting this site