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.