ellis@EDDIE.MIT.EDU@siemens.UUCP (02/25/87)
The Role of
a Window Manager
for X
Ellis Cohen
Mark Biggers
Joe Camaratta
Siemens RTL Tiled Window Project
Siemens Research & Technology Laboratories
105 College Road East
Princeton NJ 08540-6668
...!siemens!ellis (uucp)
ellis@siemens.siemens-rtl.com (csnet)
Ellis.Cohen@a.gp.cs.cmu.edu (arpa)
25 February 1987
The architecture of X Version 11 permits client basic requests to the
window server, such as those that open or resize a window, to be
redirected to a window manager client. This manager-client can enforce
a desired desktop layout, either directly under user control or
automatically.
But what should be the proper role of a window manager, and where
should code for manager functions be located? In this note, we will
describe a functionally complete manager and what support we think
should be provided by client applications for window management.
Our comments are based on our experience in building the Siemens RTL
Tiled Window Manager which runs under SunView and is now being ported
to X.
1. Where Does the Manager Play?
Window manager functionality could be linked into each client
application, could be present in a separate window manager process, or
some combination of these two.
SunView is an example of a system in which each client links in code
which provides the user interface for window operations. This includes
code which adds a border and header to a window, and which intercepts
mouse events in those regions to expose, hide, resize, move, and zoom
windows, and to bring up a menu of these and other window operations.
Clients of X could be and have been implemented in exactly the same
way. The header and border regions could be a separate window also
"owned" by the client. The client could get events directed to these
regions and then request X to perform the primitive operations needed
to implement them.
We believe that this extreme is not a correct or appropriate approach,
for a number of reasons.
- Some window management operations may involve more than one
window at a time - clients would have to talk to each other
about pending operations.
As an example, the Exchange operation in our tiling manager
is used to exchange the locations of two windows. An open
window can also be exchanged with an icon, which closes and
iconifies the open window and opens the iconized window.
- It is costly in space, since without shared libraries, each
client replicates the same window manager code.
- In systems that do not support dynamic binding, this approach
binds the choice of window manager to the application too
early.
- Changes to the window manager require relinking of
applications. which is not necessary if the user interface
is handled by a separate manager-client.
2. The User Interface to Window Operations
2.1. Window Dressings
In our window manager, when a window is created by a client, the
manager "wraps" another window around it, which is owned by the window
manager. The outer window is used by the window manager for drawing a
header, borders, and a number of gadgets.
The header bar may contain the window class (typically reflecting the
name of the application), the host machine that the application is
running on, and any other information supplied to the manager by the
application. When the window becomes the input focus, we reverse the
color of the header.
It is appropriate for the window manager to fill in the header, since
it needs to know the contents of the header anyway, since (as we
describe below) we use it in supporting closed window lists, icons and
profile files.
Gadgets are used to show window status (as known to the window manager)
and as accelerators for window operatiions (rather than picking them
from a menu). A move gadget is used to move a window or exchange two
windows. The zoom gadget is used to "zoom" a window and indicates
whether or not the window is zoomed.
Other decorations, such as scroll bars and radio buttons, are not
provided by the window manager. They are generally application-
specific, probably to be provided by an X window toolkit and linked in
with the application.
We may consider supporting a middle ground -- where the client draws
the border and header, but informs us (through window properties) of
its size, so that we can intercept input in that region. The details
have yet to be worked out.
2.2. Icons and Closed Windows
The window manager keeps track of closed windows and allows the user to
open them. For users who do not wish icons, we provide a pop-up menu
listing the closed windows. The menu entry is exactly the contents of
the window header. In our current system, it contains the window class
(e.g. h19 -- an h19 emulator) and window info (e.g. /bin/csh --
indicating that the h19 emulator is running the c-shell), strings
provided by the client, as well as the host on which the emulator is
running.
For users desiring icons, we create them and place them on the desktop.
We support icons built from the window header info, from a pixmap
supplied either in a profile or by the application, or allow the
application to draw the icon in the same or a different window.
We also decorate and highlight icons. We highlight icons to indicate
the "state" of the window as indicated by the client. We probably
won't go to the lengths of the Sapphire window manager (which indicated
when input/output was pending as well as the degree to which the job
being run in the window was completed). But we can reverse the icon,
for example, when notified by the client.
In addition, we highlight an icon when a client has tried to open a
window and the window manager did not permit it. For example, for
various reasons, the windows on the screen way not be permitted to be
either shrunk or closed automatically (as a side effect of an operation
on another window), so that opening a window by the client would be
impossible. Highlighting the icon indicates this fact.
Support for icons could, of course, be linked in with the client. The
issues are similar to those discussed above.
Once again there is a middle ground. The icon window could be created
by the application, and made an attribute of the main window. The
window manager would decide when and where to open the icon, and button
clicks in the icon could be intercepted by the window manager, but the
contents would be wholly drawn by the application.
2.3. Transient Windows
Applications often create "pop-ups" or "dialogue boxes", which are
really transient windows. However, the user may do some work in
another window (often "cutting" something out to paste into the
dialogue window) while the dialogue window is up. The dialogue window
may be in the way of this other window, and this needs to be managed by
the window manager in some way.
- The manager can layout a dialogue window just as it does an
ordinary windows. For our tiling manager, this would mean
tiling it. That is almost certainly the wrong thing to do,
since it would disturb the tiled desktop unnecessarily.
- The window can be overlaid where the application requests,
and then be decorated so that it can be moved about by the
user. For an overlapping window manager, this is no
different than the first alternative. For a tiled window
manager, the window decorations for overlying dialogue
windows would have different semantics than those for tiled
windows. This is not an unreasonable alternative, but would
need to be done in the least confusing way.
- The manager could do nothing with the window -- the
override-redirect attribute would be set. Either the
dialogue window could not be moved, or window decorations
would be provided by the application. This is probably the
worst solution. If the dialogue window can't be moved, then
it may be covering a window containing information that the
user wants to copy to the dialogue window. If the
application provides the means to move it, then different
interface semantics for the window manager (at least ours,
anyway) and the application are almost certainly assured.
We are planning a somewhat different approach. It assumes that the
dialogue window is associated somehow with a "regular" window -- we
call this window its "dialogue-parent", and a property known by this
name would be associated (by the application) with the dialogue window.
In our model, when the user moves the cursor outside of the dialogue
window (or perhaps clicks in the header of the dialogue window), the
dialogue window is lowered to the bottom of the window stack. This
allows the user to work in other windows. When the mouse is clicked in
the header of the dialogue-parent, the dialogue window is raised back
to the top again.
As an option, we will have the window manager place the dialogue window
so that it overlays (as much as possible) the dialogue parent. If the
dialogue parent is moved, the window manager moves the dialogue window
along with it.
We still could decorate the window to allow it to be resized and moved
(though there should be no need to raise or lower it). However, if we
keep the dialogue window over its parent, and assume that the
application picks the appropriate size, this should rarely be
necessary.
3. Window Properties
3.1. Properties and Classes
A variety of window options control both the appearance of a window and
the semantics of window operations. For example, in the Siemens RTL
Tiled Window Manager, the option "RequireManualClose" prevents a window
from being closed as a side effect of an operation on another window.
(Since there is no overlapping, a window can be closed automatically to
make space when another window is enlarged or opened.)
Window options can be set in three ways:
1. By the application.
2. By the user, through the user interface.
3. Via a profile read in by the window manager.
X Window Properties are used for options that do need to be set by the
application to properly support a window manager. These have been
proposed and defined in an accompanying document, "Standard X Window
Properties which should be set by X Applications".
Most options, such as "RequireManualClose", do not need to be set by
the application, and thus do not need to be X Window properties, but
can be represented internally by the window manager.
A small number of options, including "RequireManualClose" and
"FixedCompletely" (which prevents a window from being automatically
moved as a side effect of an operation on another window) may be set by
the user through the interface.
The remaining options may be set in a profile file which is read in
when the window manager is started, and may be re-read on explicit
command by the user (via a selection from the window manager menu).
The profile cannot be used to set options on individual windows but is
used to set options on all windows from a given class.
The "WindowClass" is a window property set by each application, and is
used by the window manager to obtain other options from the profile.
Window classes form a hierarchy, with multiple inheritance of window
properties. The window class hierarchy is defined by SuperClass
entries in the profile.
Currently we are using the same profile format used by CMU's Andrew
system for its preferences file. In any case, we think it would be
useful for all X window managers to standardize on a single profile
file format.
3.2. Saving and Restoring Desktop Layout
The ability to save the current window layout, and arrange for the same
applications to be run with the same windows in the same location is
very useful. For example, SunView reads a ".suntools" upon startup
which may have been previously generated by the "toolplaces" command.
To operate in the same way that SunView does would require the
following:
- Each application must accept command line arguments
indicating the location of the window as well as other window
properties that are to be saved. After starting, the
application would have to set the corresponding X window
properties of its main window.
- Each application would have to save, as a "Command" property
of its main window, the command string used to invoke the
application.
To save the current configuration, the window manager would visit each
window, edit its Command property to reflect the current window
location and properties, and store it is a startup file which could be
executed by the window manager at a later startup.
This approach requires that all applications behave as indicated above.
If an application does not specify a "Command" property for its window,
an entry for the application will not appear in the saved
configuration. Even worse, if all applications do not participate in
accepting and setting window location and properties, then this scheme
simply breaks down.
Consequently, we have adopted a different scheme in our window manager.
We expect the user, not the window manager to build a startup file (in
our case ".rtl.startup") which is simply a set of commands for starting
up applications. There is no need for window locations or properties
to be passed on the command line.
The window manager has a "Save Layout" command (selected from the
window manager menu) which builds a separate layout file (in our case
".rtl.layout") listing each window on the screen -- windows are
identified by their window class and host -- along with its location
and window properties.
When the window manager is subsequently restarted, the startup file is
executed. As applications open windows, the windows are matched to
descriptions in the layout file to determine their initial location and
properties. The main danger of this approach is that our users are
used to "toolplaces" and forget that when they change their startup
file, they either have to resave the layout file or manually edit it.
Another problem is that we cannot differentiate between two
applications which run on the same host and which use windows of the
same window class. The applications will probably be different if they
were invoked via a different command line. So, on X, if a window does
have a "Command" property, we will save it in the layout file, and use
it when necessary to distinguish between applications.
This will not be enough to distinguish applications which differ due to
differences in their environment upon initialization. Such
applications may store a string in an "Identification" property which
will be stored in the layout file and used instead of the "Command"
property.
4. Conclusion
We have described what we believe is the role of a window manager under
X, and how clients need to provide information through window
properties to support it. The properties have been described in an
accompanying document, and need to be standardized.