This section summarizes the results achieved at the Final Session where the Working Group Reports were submitted. Each Group made comments about possible areas for future work and these were discussed and relative priorities established.
Window managers are not yet in widespread use and few people have experience of using window managers and developing applications in a window manager environment. There was a clear consensus that the UK needs to gain experience in these areas.
Recommendation: Make window managers more widely available and put effort into developing expertise in writing applications for a window manager environment.
There was general agreement that the Application Program Interface was better understood than the Operator Interface. Existing systems had large differences both superficially and architecturally. However, many had similar interfaces to the application particularly if it is assumed that the application interfaces to the window manager via a graphical toolkit.
There was a view that an application interface could be agreed even if many other parts of the window manager system required fuller study. This would give applications the ability to move from one environment to another without extensive change. The experience with existing window managers is that it is difficult to port applications from one to another if the facilities provided by the window manager are used in anything but a trivial manner.
Recommendation - Short Term: Define an Application Program Interface (possibly at more than one level) that can be used by the second generation window managers currently under development.
A major research area is discovering how graceful interaction can be achieved by an application running under a window manager. Portability and device independence are difficult to achieve without sacrificing the ability of the application to use the facilities provided by a particular hardware configuration. The meeting was impressed by the work of Gosling in downloading procedures to the window manager from an application in a device independent language to allow a more intimate connection between the application and hardware. While not believing that all the problems had been solved, there was a strong feeling that research should be conducted in this area to establish the viability of this approach.
Recommendation: Define and implement a window manager using downloading of procedures to achieve both a higher level interface between the application and window manager and a closer control of input by the application.
The work of Rosenthal and Gosling has indicated that it might be feasible to achieve a portable window manager that could run efficiently across a range of hardware if constraints were applied to the level of functionality provided. The idea of producing a Level 0 portable window manager received some support. It could be used as a vehicle for testing the application program interface defined above. A major advantage would be that it would provide an environment in which comparative studies of applications on different hardware could be achieved.
There was general agreement that we needed more effort in producing applications that ran under window managers so that experience could be built up into their use. Doing this on First Generation Window Managers tended to waste significant time getting round the problems arising due to the early design.
Recommendation - Short Term: A Level 0 portable window manager should be defined using the "standard" API and implemented on a range of hardware.
A major topic of the Workshop was establishing a model of substructuring for windows which included window boundaries, pop-up menus and icons as specific examples of a more general facility. An attempt was made to put a preliminary proposal forward. In the time available it was recognized that the model was incomplete and did not address all the problems.
Recommendation - Short Term: Establish a consistent model of substructuring which encompasses icons, window borders, pop-up menus etc.
The User Interface was the area where more problems were raised than solutions proposed. It was demonstrated that window managers had many of the usual problems of the human-computer interface. The user needed to be able to understand the model of the window manager. Experience needed to be gained in assessing different styles of user interface. The balance of control between the user and the system needed to be analysed. Consistency of style in the interactions to the window manager and application must be provided.
There was a strong desire that any window manager should be customizable, configurable and extensible at the user interface to cope with the requirements of a wide range of users. Tools needed to be provided so that prototype systems can be produced and tested quickly. It was clear that the requirements for a User Interface Management System differed when interaction was being performed in a window manager environment.
Recommendation: Much more hands on experience needs to be gained and prototype systems for experimentation need to be developed.
Many issues were raised in this area. While believing that the OKS input model had provided a basis for future discussion, it was not clear that it was applicable in the window management environment. Sneak paths were needed between the device input and the associated echo. How should this be fitted into an overall model? How should ordering of events be handled to ensure correct ordering while allowing mouse-ahead etc? What issues arose due to the use of a Unix operating system?
Recommendation: A better model of input in this environment needs to be defined.
While believing that it was too early to standardize a window manager, there was some hope that agreement at the Application Program Interface might be possible.
The activities by the ANSI graphics community in putting forward proposals needed to be tracked and similar activities in the UK should ensure an input into this arena. The long time needed to establish standards probably means that it is time to start the process as a method of exploring the methodology.
Recommendation: The UK should track the ANSI standards activities.
The ability to move information between one application's window and another window associated with a different application was a useful and desirable facility. There were clearly problems in establishing the sensible functionality.
There was a view that cut and paste facilities could be bolted onto existing window managers to establish the functionality required even though the implementation would be far from optimal. It would give valuable insight into the required functionality.
Recommendation: Cut and paste facilities should be implemented on existing systems as research prototypes to assess their relative merits.
Distributed systems raised a number of new issues, accentuated particular problems and provided criteria for assessing two different approaches. It was felt that the impact of moving to more distributed systems would be significant and more effort needed to be put into seeing the particular problems of distribution in a window management environment.
Window managers are still in their infancy. The second generation of window managers should provide answers to many of the more pressing problems. However. significant research and experience is still needed before the area can mature.
As a caveat, the general view is that the window manager is not that important long term, being servant to both the application and operator. While it is an important area of activity for research now, it is hoped that a methodology can be established that does not require a large on-going activity in this area. The urgency now is due to the recent explosion of bitmap displays which make this area one of timeliness and promise at the moment.
