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:

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:

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:

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:

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:

(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.