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.