GUIs depend on more than just a graphics toolkit. They need a framework, an integrating environment to help them communicate with one another and the rest of Unix. Because GUI environments normally aim at supporting some variant of the virtual desktop metaphor pioneered by the Alto, they are often referred to as “desktop environments” or just “desktops”. Among the things such a desktop environment typically supplies are the following:
The default behavior of your toolkit library will supply part of your interface's look-and-feel choices, but most of them will come from the policy set by your GUI environment. Where toolkits supply simple widgets like buttons, text-entry boxes, and scrollbars, GUI environments combine these to produce compound widgets with a consistent look and feel — scrolling menus, combo boxes, menu bars, progress indicators, and the like.
A window manager is the GUI analog of a shell. Though the term “window manager” is traditional, these programs might better be called “interface managers”. They handle mouse clicks on the screen background, supply frames with maximize/minimize/dismiss (and possibly other) buttons for windows, support moving and resizing windows, support launching and dismissing applications, and provide a hosting environment for specialized application launchers like toolbars or docks.
Modern window managers are usually associated with one or another of the two major toolkits, GTK or Qt, though a few of the older ones use the Athena widget set or go to Xlib directly. Modern window managers are also usually themable, which means their visual appearance can be varied by supplying a resource file of widget decorations and colors. Changing themes does not change the logic of the window manager controls.
We won't go into great detail about different window managers here because nothing about them tends to have much impact on writing application GUIs. A brief survey of the alternatives available other Linux and other modern Unixes in mid-2004 follows: for a more in-depth look at these and others, including screenshots, see the excellent Window Managers For X website.
Uses Qt. Themable. This is the window manager shipped with the KDE desktop environment, and is very tightly integrated with it.
Uses GTK. Themable. This is the default window manager shipped with GNOME.
Uses Athena widgets. Themable. Tries to capture the look and feel of the old NextStep workstations, a fondly remembered series of Unix machines from the late 1980s.
Uses GTK. Themable. This was at one time the default window manager shipped with GNOME, untill they switched to Sawmill/Sawfish. The author is a visual artist and Enlightenment features particularly elaborate eye candy.
Can use Qt or Motif. Its major selling point is that it has a very small memory footprint; it tends to be valued by people who want a modern but minimalist approach in their window manager.
This window manager is mainly of historical interest and is listed here mainly because some pieces of X documentation refer to it; it is no longer actively maintained. It used to ship with X, and before the post-1996 Unix renaissance was for many years the leading edge in window managers, but is very spare and feature-poor by today's standards. The OpenLook screenshot in the history chapter appears to have been made on a system using twm. There are a couple of minor variants, including vtwm, tvtwm and ctwm; some of these are still maintained.
Uses Xlib; can optionally use GTK. Themable. fvwm2 is a modern descendant of twm, and is intended to carry forward the twm tradition of a very simple desktop with programmer-oriented configuration while also adding a few modern flourishes such as themability.
Users expect to be able, at a minimum, to be able to use the mouse to copy or cut text from one application window and paste it into another. GUI environments normally provide some sort of simplified interface to ICCCM, the protocol documented in the X11 Inter-Client Communication Conventions Manual, to enable applications to handle cut and paste properly.
ICCCM also allows applications to post hints to a window manager about the preferred locations, sizes, stacking behavior, and other properties of their windows. GUI environments provide consistent defaults for these hints and (often) easier ways to post them than bare Xlib supports.
More advanced GUI environments support drag and drop of files and icons into and between applications, with the application performing some customized action on the payload. ICCCM alone will not enable this; it requires something like an object-broker daemon running in background, and a GUI-environment-specific notification protocol that tells applications when they need to query the daemon. Much of this complexity, including the interface to the object broker, is normally abstracted away by service libraries shipped with the GUI environment.
Since there is only one sound card per machine but multiple applications may contend for use of it, access to the sound card needs to be either serialized or mixed. This is normally handled by a sound daemon shipped with the GUI environment, with applications sending requests to the daemon through yet another service library.
The libraries shipped with GUI environments often include other kinds of services for application programming that are not strictly related to GUI support. They may supply a lightweight database facility, for example, or code for parsing and reading a generic configuration-file format, or support for internationalization via message catalogs.
When GUI environments get into functionality arms races with each other, this is one of the places where the consequences often show up. Some call these additional services features, some call them bloat, and the arguments over which are which frequently degenerate into religious wars. You have been warned!