Kenton Lee

Work With Your Window Manager

by Kenton Lee

November, 1995

Copyright © 1995 Kenton Lee, All Rights Reserved.


Last month's Advanced Application Development column[Lee10-95] discussed proposed extensions to the X Consortium's Inter-Client Communication Conventions Manual [ICCCM] to add support for multimedia data interchange. The ICCCM describes important conventions that all X clients must follow to interoperate in a multi-client environment. Specifications for data interchange through selections, as I discussed last month, are an important part of the ICCCM. In this month's Advanced Application Development column, I'll cover another important part of the ICCCM: interaction between X client application programs and the X window manager.

X programmers often misunderstand the role of the window manager. Programmers often ask me questions like:

The answer to all of these questions is that, with very few exceptions, X application programs should not directly implement any of these features. The window manager implements them and application programs should request them only by communicating with the window manager. The ICCCM describes the protocols that the application programs should use for this communication.

The ICCCM protocols can be complex to implement using Xlib[Scheifler]. Fortunately, the X Toolkit[McCormack] and OSF/Motif[OSF] provide much simpler, higher level application programming interfaces (APIs). In this month's column, I'll review the ICCCM's separation of functionality between the window manager and X application programs. I'll also discuss the major X Toolkit and Motif ICCCM APIs for dealing with the ICCCM protocols.

I won't discuss the ICCCM in great detail. It covers most of its material very well and I recommend that you study it.

Window Manager Programming Model

My June column[Lee6-95] discussed my programming model for X application programs. The window manager fits in to that model in two ways:

  1. X Toolkit-based application programs generally interface with the window manager only through their shell widgets. In most cases, the window manager only interacts with top level windows (i.e., shell widgets). Application programs are responsible for widgets beneath their shell widgets.
  2. The X Toolkit and Motif encapsulate most ICCCM window manager protocols with standard X Toolkit programming interfaces: resources and simple convenience functions. Applications should use these interfaces whenever possible.

In the following sections, I'll discuss the primary application programming interfaces to the ICCCM functionality. You may find that you were using some of them already, without realizing that the functions are really handled by the ICCCM and the window manager.

X Toolkit Shell Widget Resources

As I've discussed in previous columns[Lee3-95,Lee6-95], widget resources are the X Toolkit's primary programming interfaces. The ICCCM APIs are no different. The X Toolkit's WMShell widget (and its subclasses, such as TopLevelShell and XmDialogShell) encapsulates many of the ICCCM protocols as widget resources. Simply setting the resources will cause your application to participate in the protocols.

Note that most of the resources are hints, not demands. Most modern window managers support all the protocols, though some may decide not to implement some of them some or all of the time.

The major ICCCM-oriented WMShell resources are:

Some additional ICCCM protocols are implemented via other shell widget resources:

Xlib-only application programmers must write a large amount of code to implement the ICCCM window manager protocols. X Toolkit application programmers have a much easier time. Simply set the appropriate resources and the X Toolkit does the rest.

ICCCM Convenience Functions

The X Toolkit and Motif use a convenience function API rather than a resource API for a few ICCCM window manager protocols:

Some important ICCCM protocols for which you might want to use the latter functions are the WM_DELETE_WINDOW and WM_SAVE_YOURSELF ICCCM session management protocols. These protocols allow your application programs to shut down gracefully when the user terminates them from the window manager or session manager.

Proprietary Window Manager Protocols

In addition to the standard ICCCM window manager protocols, some widget sets and window managers implement additional, proprietary protocols. These protocols are often useful, but since they only work with particular window managers and some of your customers may be using other window managers, you must be careful to design your application to still work properly with any ICCCM-compliant window manager.

Since the Motif window manager (mwm) is probably the most popular right now, I'll describe some of the proprietary protocols that it supports. Several other window managers support similar proprietary protocols.

Like the ICCCM protocols, the APIs to most of these protocols are widget resources. Motif's resources are generally implemented in Motif's VendorShell widget class. You may set these resources on any subclass of VendorShell, including TopLevelShell and XmDialogShell:

These resources generally override mwm's global resource settings.

Motif also provides a convenience function XmIsMotifWMRunning() so that the application can determine when the above resources are useful.

Overriding the Window Manager

At times, you may find it useful to circumvent the window manager and manage your top level windows from within your application. Some cases where this may be useful are:

This list is intentionally short. Remember that your X application is only one of many that your users may be running. In order for these applications to co-exist on the screen, they must share system resources. The ICCCM and the window manager help negotiate this sharing. If you bypass the ICCCM and the window manager, your application won't work very well in a multi-client environment.


The X Inter-Client Communication Conventions Manual (ICCCM) defines important conventions that your X clients should follow to ensure interoperability with other X clients that your users may be running. One important set of ICCCM conventions deal with the window manager.

The window manager is responsible for controlling important attributes of top level application windows, including size, position, stacking order, colormap focus, and keyboard focus. Your X client may request certain values for these attributes using the protocols defined in the ICCCM.

The X Toolkit and Motif provide simple APIs that X clients should use to participate in the ICCCM protocols. I've covered most of these APIs in this month's column. More importantly, I've described the programming model that separates the window manager's responsibilities from the application program's responsibilities. If you find yourself with a programming problem that appears to be within the window manager's area of responsibility, you should reach for the ICCCM and WMShell documentation, rather than the Xlib documentation.

If the ICCCM or your window manager does not provide some top level window configuration features that you need, you should reconsider your application's design. A design that violates the ICCCM will most likely not be very popular with your users.


A copy of the Inter-Client Communication Conventions Manual is included in Part III of [Scheifler]. You may also FTP a PostScript version from
Kenton Lee, "Indirect Motif Widget Resources," The X Journal, May, 1995.
Kenton Lee, "The X Programming Model," The X Advisor, June, 1995.
Kenton Lee, "X Window System Multimedia Interchange Targets," The X Advisor, October, 1995.
Joel McCormack, et al, "X Toolkit Intrinsics - C Language References," included with the X Consortium's X11R6 release.
Open Software Foundation, OSF/Motif Programmer's Guide, Release 1.2, Prentice-Hall, 1993.
Robert Scheifler and James Gettys, X Window System (third edition), Digital Press, 1992.

Ken Lee is an independent software consultant specializing in X Window System application software. He has been developing UNIX graphical user interface software since 1981. Ken may be reached by Internet electronic mail at kenton @ or on the World Wide Web at

Ken has published over two dozen technical papers on X software development. Most are available over the World Wide Web at