Window Managers

A window manager is a thing that looks after all the windows on the display. It allows you to use a pointing device (a mouse) to ask for more or less windows of a particular kind (by use of menus). It allows you to move windows around, resize them, close and open them (turn them into icons and so on. The display server is not a window manager. The window manager is actually another client of the display program (i.e. it is independent of the display hardware too). See figure #fnX1#410>. The window manager intercepts bits of protocol between the display server and the other applications, and then informs applications of special things (such as the fact they should resize or be redrawn etc.). Thus it implements the <#411#> policy<#411#>. Networked windows systems mainly use (reliable) messages to communicate between client window processes and the graphics display server. An important reason is that the server must receive events (such as input from a mouse) and transmit them to the client program, without incurring too much delay. If application level acknowledgment were required (such as is implied by a procedural type interface) the system would be a minimum of 2 times less responsive. This messaging system is often bound up for the programmer in a library of standard procedures which often have no return values or out parameters, and thus can simply send the message and return. Thus the applications programmer sees the server almost directly as a library almost like conventional device independent graphics systems. Examples of such systems include the X Windows System and the NeWS system. They are of increasing importance in Distributed Systems, since it is possible to distribute graphics processing more widely, and move a large part of what was once mainframe type processing onto the users desk. This is possible due to the change in relative cost of graphics workstations, and LAN technology. Interesting engineering tradeoffs can be made in the level at which the protocol is placed between the application and the server, whether at simply moving procedural data between the two, or graphical objects, or actual programs (active objects). The key design decision in many networked window systems is the use of messages rather than remote procedure call mechanisms. These are described in the next section.