`Look and Feel' Part 2 - Window Managers
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:
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.
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:
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:
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.)
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.
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.
The two distinct components of the total interface a user sees are:
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!)
(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:
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.
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.)
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.
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.
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.