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

21 Application Program Interface Task group

21.1 INTRODUCTION

This group was formed during the final plenary session on the second day of the Workshop and was charged with producing a set of conclusions about the application program interface. The group met for one two-hour session on the morning of the third day and then reported its findings to a plenary session. Membership of the Task Group was:

Previously these people had been in different Working Groups at the Workshop and were effectively asked to bring the insights of their previous groups to this new task.

The group had a wide ranging discussion which is summarized below. The group report as presented to the plenary session is then given along with the ensuing discussion.

21.2 GROUP DISCUSSION

The group decided their task was two-fold; first to come up with a list of principles for the application program interface and second to say something about taxonomy.

The first principle discussed was that the API should be able to do everything the window manager can do and that the user interface can do. There should be symmetry between what the client can do and what the window manager can do. It was recognized that some of the possibilities might not be terribly sensible, for example if the user decides to give an area of the screen to an application, the application should not tell the window manager to move the space elsewhere. It was also recognized that if both the user and the application can perform a given action, then some discipline must be imposed to avoid constant conflicts.

An interesting idea that came up at this stage was to have predicates in the API to allow the application to determine anything the user can determine. For example, one could inquire through the API whether window X was to the left of window Y or not. It was thought that it would also be useful to be able to say to the window manager I like this screen layout, please use it again.

The discussion then moved on to considering whether the API should be synchronous or asynchronous, ie can the window manager send signals to the application when nominated events happen. It was generally agreed that an asynchronous interface is much harder to handle than a synchronous interface. It was generally thought desirable that asynchrony should be kept to a minimum.

Hierarchical structuring of windows was discussed. The general view was that no one has yet found a use for hierarchical structuring, but that there is a need for some kind of structuring. Constructions like pop-up menus in windows can be handled by subwindow-level structuring. If the window manager is capability-based, there is a need to inherit capabilities and this leads to some form of structuring. It was also generally thought that windows needed to have attributes which define the relationships between windows. It was clear that there is a need for more work in this area.

The object-oriented programming approach was felt to be particularly appropriate for window managers. While the window manager may be object-based, this does not imply that applications using the window manager have also to be written in an object-oriented language.

There was a strong feeling that, at this stage in their development, window managers need to be very flexible. The downloading-of-procedures idea in James Gosling's work was seen as a nice way to achieve this. In this context protection issues were seen to be important. There need to be some limits on loading arbitrary code, especially since the window manager has in some sense the status of an operating system in that it must be reliable and not crash. One idea for achieving protection was through the use of applicative languages which are by their nature side-effect free.

An important aspect of the CMU window manager is that it takes hints rather than demands. For example, if the application program asks that some text be displayed in 10 point Times Roman, and this is not available, then the system will do the best it can to satisfy the requirement. Clearly it is application dependent what the strategy here should be, whether, say, to provide 10 point text in some other font, or the nearest available size in the specified font or something else. Strategies in this sense need to be programmable. Applicative languages again support one way to achieve this - through the use of higher order functions to define the strategy. However, there is no existence proof that such a system could be made to perform well.

The redraw and size change problems were again discussed. At CMU a standard module is provided which handles these problems. Most applications use it. It seems that it is not too difficult a task to write such a general purpose module and also provide hooks so that applications can add new objects. The toolkit approach was thought to be a good paradigm. Tools need to be extensible by the application. Toolkits are also a useful aid to consistency across applications.

The need for a layered approach to structuring was identified, though there was no agreement on what the layers should be, nor precisely what should be provided in the window manager layer and what is provided by a toolkit on top. The taxonomy discussion did not advance very far.

There was agreement that the interface to the window manager should be procedural rather than through shared data structures.

There was some support for the idea of providing a number of fixed window types from which richer systems can be built. A design based on fixed window types which are parameterized through a state list whose entries may be set and inquired is being pursued at Centrum voor Wiskunde en Informatica (CWI), Amsterdam.

21.3 FINAL REPORT

The following report was presented at a plenary session on the Wednesday morning.

The Task Group produced the following list of principles to be obeyed when designing window managers.

  1. Symmetry: the application should be able to do anything and enquire anything that the window manager can. Clients as well as the window manager should be able to move windows about, move them to the top, enquire about size etc. A number of these are deemed to be in bad taste but are not prohibited. For example, surfacing a window is not reasonable; but it could be used, especially if an application uses two windows, if the user surfaces one, the application should be allowed to surface the other.
  2. Synchrony: clients should be able to run as a single thread of control. Asynchrony is hard to handle, though a small degree of asynchrony (for example, asynchronous notification via Unix signals) is reasonable. The bulk of the application program should be synchronous.
  3. Hints: applications make requests to the window manager which may not be satisfiable. Graceful mechanisms must exist for coping with such situations. This makes applications more robust. There should be a graceful mechanism for clients to interrogate whether their request was satisfied, and to provide some sensible recovery if it was not (for example, if a particular text font is not available).
  4. Redraw requests: redraw requests should be hidden where possible. The redraw mechanism should be kept simple. However it must be recognized that redraw requests are an inescapable fact of life, for example when there is insufficient memory to hold off-screen copies of windows.
  5. Procedural interface: the interface to the window manager should be procedural, rather than through exposed data structures. Exposed data structures are often obstacles to evolution.
  6. High level libraries: applications probably never need to talk directly to the window manager, but instead should talk through libraries such as GKS and a window manager toolkit. Exceptions should also be handled in libraries, for example to handle situations such as non-availability of the requested font. If libraries are embedded in the window manager, then the number and types of libraries available are fixed.
  7. Strategy specification: it should be possible to specify strategies, for example for font matching or colour matching.
  8. Generality: this is hard to achieve. Compromise is likely.

21.4 DISCUSSION

Teitelman:
Referring to point (3) in your list, can you characterize the conditions under which a window manager would refuse requests from a client? It feels so soft that the user might feel uneasy. Is the window manager surly? Is it the intention that requests are honoured most of the time, and that failure is rare?
Gosling:
Yes, but failure should be handled gracefully.
Bono:
I think that there are two situations which arise from the same mechanism. The first is occasional failure such as a disk crash. The program environment should be robust enough to deal with it. The other situation is where device independence is written into the system. What happens if a colour device is used to run the program today, where a black and white device was used yesterday? This may show up in the same mechanism, so you cannot say that it is rare.
Gosling:
When an application makes a request, it should nearly always be satisfied. The application program can inspect the result to see if it is satisfied exactly. If it asks for pink and it doesn't get it, it should be able to find out what it did get. Only then should the application deal with the complex recovery strategy that it may need. We need some sort of strategy specification. What sort of strategy should we use to select a font or colour if there is no exact match? What feature is more important in matching a 10 point Roman font, its size or its typeface? At CMU, if you point at a thing and want 14 point Roman you may get 14 point Cyrillic, which is not very useful.
On point (7), are you implying a dynamic strategy, or one determined at system configuration?
Gosling:
Harold (Thimbleby) is all for downline loading this. In reality this is not usually very easy. GKS adopts a compromise - an integer is used to select a predefined procedure. As you may only have 32 bits, this does not give you many Turing machines. Something of that flavour would not be a bad idea.
Cook:
Justify synchrony in point (2).
Gosling:
This is mostly a matter of complexity of program. Not many languages handle asynchrony very well. If we have Cedar or Mesa then this is possible.
Teitelman:
How we do it in Cedar is that the application is given the opportunity to take action. In Mesa we require that the application catches the signal and takes any action. In the absence of the application program intervening, something sensible should be done, but it may impose a little bit more of a burden on the implementer.
Gosling:
In Unix software there is no synchronization around data objects. In Cedar/Mesa there are monitors which continue while the mainline code is running; there are no notions of interrupt routines.
Teitelman:
This is a single address space system. We are unlikely to see this in Unix systems.
Newman:
How realistic is it to design an interface using your criteria?
Gosling:
Bits and pieces already appear all over the place. The CMU system deals with most of this OK, but is poor on symmetry. The SUN system is good for symmetry, but not for synchrony. It is terrible on hints, and has problems with redraw requests. There is no intrinsic reason why we can't deal with all of these though. The problem is dealing with them all at the same time.
Williams:
A point that I read in the SunWindows manual was that once a client has done a 'create window' then the process will probably get a signal to redraw its windows for the first time.
Gosling:
Right, but it's a case of maybe rather than will. Some programs may redraw and redraw again if multiple events aren't handled very well, and give screen flicker.
Hopgood:
Do you have a view on the level of interface to the window manager?
Gosling:
Clients don't want to talk to the window manager at all, but should talk to something fairly abstract. Do you want to talk about this as the window manager as well? The window manager shouldn't implement scroll bars, or buttons or dialogues, we need another name for the thing which handles the higher level operations.
⇑ 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