# Chapter 8-

`Look and Feel' Part 2 - Window Managers

#### Introduction

So far we have been dealing only with a single application, and have concentrated on how the user interface within that application is built up. However, to make the most of any system we need to be able to use several applications simultaneously on screen, and even for a single application we often need to have multiple windows - for control panels, or dialogs, or to be able to view several sets of information simultaneously. We need a way to control the initial placement of these windows and to manage them as we proceed with our work; this function is provided by the window manager. In this chaptec we look at what the window manager is, and how its appearance and behaviour form the second major part of the overall look and feel that the user sees. This introduces the scenario of multiple simultaneous X clients, which we expand on in the chapter after this.

## 8.1 What you need a `window manager' for

The window manager is what you use to instruct the system to configure your screen as you want it - to move or resize windows, turn them into icons, etc. The interface the window manager presents is the second part of the total look and feel which the user sees.

As we mentioned in Modules 1.2 and 3.1.1, the base X system - the server - has no in-built means for you to tell it how the windows on the screen are to be laid out and managed. So you need an `agent' which performs actions on your behalf, in response to commands (in some form which we have yet to discuss) from you.

At its very simplest, the problem is: if you have a window on the screen and you want to make it bigger (or smaller), how can you tell the system to do that? What if you need to move windows to different positions on the screen, or bring a particular window to the top of the stack if it's obscured by some other windows? Unlike the application interface, this function cannot be provided by the application itself, because a change in one application may require changes in another; for example, if your application windows are to be tiled (Figure A), expanding one window requires that one or more others be reduced.

The answer is, you need a special program called a window manager which will interpret some special actions you take and manage the windows on your screen accordingly. Any X program that performs these functions for you is a window manager. So, many different window managers are possible, and in fact many have been developed by different organizations over the years. Facilities the window manager should usually provide include:

- Configuring application windows on screen as mentioned above, including moving, resizing, stacking, and initial placement when a new window is created.
- Changing windows into icons - small, often pictorial, representations of windows - to save sereen space when the window isn't required, and changing icons back into windows again. Not all window managers use icons; others do, and support a special icon box which keeps the icons arranged neatly, while still others let the icons be positioned anywhere.
- Maintaining particular window layouts on the screen. For example, a tiling window manager will not allow application windows to overlap, but will always try to use as much of the screen as possible, as illustrated in Figure A.
- Directing the keyboard input to different applications, that is, controlling the keyboard focus. There are two types of focus policy:
  1. Click to type, where you click with the mouse on a particular application, and all keyboard input goes to that application, no matter where the mouse pointer is.
  2. Pointer-driven focus, where the input is sent to whichever application currently contains the mouse pointer. (If the pointer isn't in any application window, the input is just thrown away.)
- Handling colormaps. As we discussed in Module 3.6.3, some applications need to use so many colours that they have to have a special table of colours - a colormap - which has to be installed into the colour graphics hardware each time that application is active, so that it shows its graphics in the correct colours. If an application does use a special colormap, the window manager installs that colormap when the application receives the keyboard focus (and of course de-installs it when another application received focus and has its own colormap installed), as we described in Module 3.6.3.

  The window manager has to perform this task because there is a deficiency in the X protocol: a race condition can arise if more than one client installs colormaps, so to overcome this the X convention is that only a window manager may install colormaps.

In the next module we look at some facilities provided by more advanced window managers.

###### Figure A. A tiling window manager expands windows to fill as much of the screen as possible.

### 8.1.1 Optional and advanced window manager functions

Extra functionality and more sophisticated features have been added to window managers as the number of window managers available has increased.

In the early days of X, many window managers were developed, because people were investigating how best window management ought to be addressed. Many of the best features of these early window managers have been incorporated into more recent implementations, and in fact new prototype window managers are still continually produced. As a result, many window managers now offer a range of features far beyond the necessary minimum, such as:

- Pop-up menus. Most window managers now let you define your own popup menus, both to invoke functions the window manager itself provides, and to run other X and non-X programs (Figure A).
- Configurability. Early window managers had fixed ways of invoking their window configuration functions, or at best somewhat limited facilities for customising them; for example, to move a window you had to press the Meta key and drag the window with the left mouse button. However nowadays most let you choose your own set of keyboard and mouse sequences for invoking the functions, and you can configure them for use on systems which don't have a mouse at all.
- Operating on groups of windows. More sophisticated managers let you select several windows and perform an operation on them as a group, for example moving them or iconifying them as a unit.
- Providing a virtual desktop - effectively a virtual screen which is much larger than the physical one; the physical screen is a viewing port onto this larger area, and you can move the port around to access different sections of the overall desktop (Figure B). This lets you group together sets of windows required for a particular activity. You place different sets in different areas of your virtual desktop, so that most of the time they are not visible and don't clutter up your screen space. However, when you want to perform that particular task, you move the viewing port to that area, so you have all the applications you need group together exactly as you left them before.
- Programmability. Some of the more recently developed window managers are programmable, especially those emerging from the research community. For example, gwm is programmable in Lisp.

###### Figure A. Configurable pop-up menus let you run other applications easily

###### Figure B. Window manager `virtual desktop' controller.

## 8.2 Using the window manager

Because the window manager is not part of the server, but is a separate X client, you can easily replace it. While only one window manager can be in use on a display at any particular time, many different window managers can be in use on the same network simultaneously.

The window manager is not built into the server nor into the operating system, but is `just another' client program. This feature has many important consequences for the system as a whole:

- It is easy to change the window manager. If you don't like one, you can choose a different one. (You can even do this halfway through a session - just kill off one window manager, using whatever operating system command is required, or the window manager's Ouit or Exit function if it provides one - and start the other.)

  This flexibility was one of the design goals of X - rather than giving a single fixed interface, to provide mechanisms that can be used to build any desired interface. (Another example of the `mechanism, not policy' philosophy.)

- You don't always need a window manager, although for normal working, one is almost essential. (Otherwise you may find that all new windows are created in the top left corner and cover up other things you are working on, and that it is impossible to place a control panel where you need it.)

  However, if the user only ever works with a single application, with a fixed configuration, it may actually be more convenient not to have a window manager. For example, a data-entry clerk might work with the same part of the same application all day, and no changing of window configuration is ever needed. Or, for a critical application such as a power-plant control system, you certainly don't want the user to be able to iconify the application's window or cover it up with another one, just in case an important warning message alert appears on the system.

- Each user on a network can choose their own window manager which suits them best - there is no requirement (other than ease of administration and training, and cost) for everybody in an organization to use the same window manager. Different window managers may suit different classes of users. For example, programmers may prefer something different to secretaries.
- As the window manager is just a client program, it can run remotely over a network. Figure A shows a window manager executing on machine `A', but managing the windows on the display of machine `B'. Where the display is an X-terminal, which can only execute the server and no clients, the window manager must be run remotely. (Although, as we mentioned in Module 3.2.2, some X-terminals do have a window manager built in now.)

###### Figure A. The window manager can manage a display on a different marhine to the one it's executing on.

## 8.3 The window manager's look and feel

Each window manager has its own distinctive appearance and its own way of providing window management functions; therefore each has its own look and feel which is independent of the interface provided within the application windows by the applications themselves. Because managing screen and window layout is such a large and visible component of using a window system, many people identify the look and feel of the window manager with the look and feel of the whole system.

You use different window managers in different ways. Some add title-bars and other decorations around the edge of the application window, as shown in Figure A. (You use these to configure your window; for example, to resize you drag on one of the edgeor corner-decorations, and to iconify you click on some particular part of the title-bar.) Other window managers add only title-bars, and still others add nothing to the window, so that to perform an action on a window you have to use a pop-up menu, or press a particular combination of mouse and keyboard strokes. (For example, to move a window you might have to drag with the left mouse button, with the Alt key pressed down all the time.) As we mentioned in Module 8.1, different window managers handle icons in different ways, perhaps keeping them in a neat icon box; Figure B shows two styles of icon box, one of which uses scrollbars to allow you to get to the icon you want, whereas the other expands to accommodate the number of icons it has to hold, and assumes that you have enough screen space for the whole of the box to be visible.

So, window managers have distinctive visual appearances, and you use them in different ways because the commands they respond to are different. In other words, each window manager has its own look and feel. Because configuring windows and managing your screen space is such a frequent activity, it is the look and feel of the window manager that most people regard as the dominant characteristic of a window system. For example, it is largely because the Motif window manager's title-bars and borders (shown in Figure A) are so like those of Presentation Manager, and behave in the same way, that Motif and Presentation Manager are regarded as providing more or less the same look and feel. (There are many other similariaes as well, but window management is the most important.) And one of the most striking features of OPEN LOOK is its `push pin' feature, which lets you `pin' dialog boxes and menus to the screen (Figures C and D) inhibiting the menu popping down when you've made your selections. You use this feature where you want to invoke a function repeatedly, and popping up the menu each time as well as selecting the function from it would be awkward.

It is very important to realize that the window manager's look and feel is completely separate from the look and feel of the user interface within a particular application, and

we deal with this in detail in the next module.

###### Figure A. Decorations added around a window by the Motif window manager.

###### Figure B. Different styles of iconbox used by the Motif and twm window managers

###### Figure C. OPEN LOOK menus and dialogs have a pushpin.

###### Figure D. Menu kept `popped-up' with a pushpin

### 8.3.1 The management interface and application interface are totally separate

The overall interface as seen by the user consists of two separate partsthe application interface built into the application program, and the management interface provided by the window manager. The two are completely separate even though the user may not notice this.

The two distinct components of the total interface a user sees are:

1. The application's user interface (the application interface) which is built into the program and remains fixed. This is usually provided by means of a toolkit as we discussed in the last chapter. To change this interface you would have to modify and recompile the source code of the program.[Footnote:While this is no longer 100% true for applications built with dual-interface toolkits (Modules 7.5 and 7.6), the argument remains broadly correct: an application can only provide the interface or interfaces that were built into it when it was compiled. For example, to add a Macintosh-like look and feel, even OI and MooLIT applications would have to be extensively modified and re-compiled.]
2. The window manager's interface (the management interface) is determined by the window manager, and if you run a different window manager, then you get a different management interface. This is illustrated in Figures A, B, and C which show the contributions made by the application and the window manager to the overall interface. Everything within the window border `belongs to' the application, whereas everything outside - the decorations, etc. - belongs to the window manager.

A different way of thinking of this is to consider that the window manager treats windows as pieces of paper on your desktop without looking at what is written on the pieces of paper; it is the applications themselves that know what is on the pieces of paper, what they mean and how you work with them.

How does the window manager gets its look and feel? The answer is clear when you remember that the window manager is just another client application - so it too has its user interface built into it, with the toolkit or other libraries it was compiled with. For example, the Motif window manager mwm is compiled with the standard Motif toolkit, and so the look and feel of its menus, scrollbars, etc. are the same as for all other Motif applications. As a result, for someone using only Motif programs, the whole interface including both management and application parts is very consistent and the user will not realize how the various aspects of the interface are being provided internally. Of course, if you use a Motif window manager with OPEN LOOK applications, the interface won't look so homogeneous. Other window managers are built using non-standard toolkits and will have a completely different, non-standard, appearance.

This separation of management and application interface is an explicit design goal of X. In general, applications should be independent of window manager policy, so they can work correctly on as wide a range of systems as possible. An application can be written to take advantage of special facilities provided by a specific window manager, and will work particularly well with that window manager, but it should still be written to operate satisfactorily and adequately with other window managers in general. For example, the OPEN LOOK window manager includes a status/error message atþa in the decorations it adds to an application window - an application can reasonably display its error messages here. Other window managers don't provide this feature, so when running with a different window manager the application should explicitly display the message in some other way, probably as a pop-up dialog window (rather than just not giving the message to the user at all!)

###### Figure A. The application interface

###### Figure B. The window manager's contribution - the management interface

###### Figure C. The overall user interface.

## 8.4 How a window manager works

The window manager is not part of the server, but is a separate X client. Most of the mechanisms it uses to manipulate the windows on your screen are not special, but are the same mechanisms any application uses to handle its own windows and sub-windows.

(If technical details aren i so relevant to you, you can skip over this module.)

In X there is no protection mechanism on a per-window basis: if an application has access to one window on a display, it has full access to every window on that display. Because the window manager is just another application connected to your display, it has full access to all the windows on your screen, and can resize them or move them or whatever else it needs to do.

So, the window manager is not using any special system mechanisms to manipulate the windows. Instead, it is just using the ordinary Xlib function calls which any program may use to configure any of its windows. This means that writing a very primitive window manager of your own is not too difficult (although writing one that works correctly and adheres to all the necessary standards is a very big job).

However, there are a few functions that are used most often by window managers, although other applications occasionally need them, too:

- Redirecting configuration operations. When a new application is created and is about to be shown on the screen, the window manager needs to know what its size and position are going to be; the window manager must also be able to change these if it needs to. (For example, a tiling window manager will often want to force a new window to be a particular size in a particular location which the window manager chooses.)

  The window manager can specify that configuration operations on the (toplevel) application windows (resize, move, and change of stacking order) should not actually be actioned but instead should cause an event to be sent to the window manager. The window manager receives the event, and itself performs the action, either as the application wanted, or as the window manager thinks fit. Effectively the window manager is getting between the application and your screen, and intereepting the configuration requests. This is how it can enforce a layout policy - tiled or overlapping windows, preventing windows being moved partially offscreen, or whatever.

- Grabbing keys and buttons. We want the window manager to receive some special events - those key or button sequences that are to be interpreted as commands to the window manager - no matter which window they occur in. Normally the server sends a keyboard or mouse event to the application which owns the window in which the event occured. To ensure that the window manager will get the events it needs it grabs them, that is, it tells the server that it has a special interest in these events, and that they are always to be sent to the window manager whenever and wherever they occur.

  Of course, this means that the other (normal) applications will never see these particular key/button sequences. So when you are using configurable window managers which let you specify which keyboard and button sequences you want to use for window configuration, you have to be careful you don't specify some keys that one of your applications might need. (You can reduce the risk of a conflict by specifying keys or buttons in conjunction with one or more modifiers such as Shift or Control or Alt.)

- Reparenting windows. We saw in Module 8.1 that the decorations around an application window are not part of the application, but are added by the window manager. X does not allow grouping of windows, so to `attach' the decorations to the window, the window manager uses the mechanism known as reparenting. In the absence of a window manager, the application windows are children of the root window; Figure A shows the window tree for this case. When the window manager starts up (or when the window manager is already running and a new application window is created), the window manager creates another window as a child of the root window; this window is made big enough to contain both the decorations and the application window. Then the decorations are created in this new window, and the application window is reparented, that is it is made a child of the new window instead of the root window. The window tree after reparenting is illustrated in Figure B. The reparenting process is effectively shown schematically in the figures of the previous module; the original top-level application window is shown in Figure A, the window its reparented to and containing the decorations is Figure B, and the final reparented result in Figure C.

  Note that this whole procedure emphasizes that the management interface - the appearance and behaviour of the window manager - is definitely not part of the application program.

In the next module we look at the mechanisms the window manager and application use to communicate with one another.

###### Figure A. Tree of windows in the absence of a window manager.

###### Figure B. Tree showing application windows reparented by window manager.

### 8.4.1 Communication between window manager and applications - properties

The client needs to communicate with the window manager, especially when the client starts, to give information about its preferred size and location, names to be used for window labels and icons, etc. Client and window manager communicate using the standard mechanism of properties.

There are strict conventions about how applications should behave in relation to a window manager. Basically, as the window manager represents the desires of the user, an application should accept whatever configuration a window manager gives it. An application should never `fight' with the window manager about the size it has been made, because that is the size that the user wanted, and the application should do the best it can to work at that size. If an application is written correctly like this, it will be `management independent', that is, it will work with many different styles of window manager, and in many different environments. These conventions are laid down in the X standard document Inter-Client Communication Conventions Manual, which we discuss in more detail in the next chapter.

In the previous module we saw that the window manager can decide to make a window any size it chooses. In order to decide how to configure an application sensibly, the window manager needs more information: how big does the application want the window to be, does it have any preference about aspect ratio (does it need a tall thin window, or would it really prefer a square one), what is the minimum size that the application can use, what is the maximum, etc.

To give this information to the window manager, the application uses properties (Module 4.1 ). A property is a named piece of data which a client can attach to a window, and which any other client may read or overwrite. Here, the application places information about its desired configuration in a number of propenies with specific names, attached to the application's top-level window. (The property names are standardthey are defined in the Inter-Client Communication Conventions Manual, and all begin with the prefix WM_). The window manager looks at these properties when it needs the information. These properties are also used to pass other information the window manager needs, for example the name of the application as it is to be shown in its titlebar. An example of the window manager-related properties of our text-editor window is shown in Figure A.

Once the application has started and its top-level window (or windows) has been configured, there is normally very little communication between application and window manager. An exception is where the application sets the WM_PROTOCOLS property on its window. The value of this property is a list of functions or actions which the window manager may ask the application to perform, and which the application is able to perform. The actions include:

- WM_DELETE_WINDOW tells the application to delete this top-level window. This is paracularly useful where the application has several windows; for example, an editor might have a separate window for each file being edited, and WM_DELETE_WINDOW lets you selectively remove any of these you don't need any more.
- WM_SAVE_YOURSELF tells the application to save its current state so that it can be restarted later, ideally in exactly the same state as it is in now, and record the command necessary to restart itself in the WM_COMMAND property. For example, a text editor would save or checkpoint all files being edited, and record which files it has in its buffers, and other status and configuration information about those files.

(If the application can't perform a particular action or doesn't know about it, that action's name is not included in the WM_PROTOCOLS property; if the application can't perform any of the standard functions, it doesn't set the property at all.) When the window manager wants the application to perform an action, it sends a <ClientMessage> event to the application, with an indication in the event specifying which action is to be performed.

We discuss properties in detail in Module 9.2, and the way that one client can send events to another in Module 9.3.1.

###### Figure A. Sample set of properties for communicating with a window manager.

## Summary

In this chapter we have seen that the role of the window manager is to act as agent for you, the user - it is the way you control the layout and other aspects of the application you are using on your display. We have looked at the functionality the window manager must provide, and how it provides it. In particular, the window manager is just another client, so it has its own look and feel which can differ from that of the applications it controls, and many different window managers are available. We looked at the mechanisms the window manager uses to perform its tasks, and we saw that it uses the same X functions as any other X application.

This chapter has concentrated on how a single application interoperates with the window manager. In the next chapter we go on from here and see how multiple clients can work together, allowing a set of separate programs to cooperate in order to provide a more integrated environment for the user.