When the X Window System was first released, no desktop environment was available. Even when Motif was released in 1989, it did not include a desktop environment; although a few proprietary desktops were available, none of them gained widespread acceptance.

If you look back at X screen dumps taken in the late 1980s or early 1990s, you will find that in most cases there were no panel bars, application launching menus, or window lists. Instead, applications were launched from file-management windows containing icons or from root menus invoked by clicking on the root (background) window, and icons representing minimized programs sat directly on the root window or in icon boxes. This was possible because most of the window managers evolved (out of necessity) basic root-menu and icon-box capabilities.

By the mid-1990s, system vendors recognized the need for a desktop manager, and in 1995, the Open Software Foundation (OSF) introduced the Motif-based Common Desktop Environment (), CDE based upon HP’s Vue environment.

Today the dominant desktop environments are GNOME and KDE. CDE continues to be the default desktop on AIX and HP/UX systems, though IBM offers both GNOME and KDE for AIX. Sun Solaris 10 includes both CDE and GNOME.

As an alternative to GNOME or KDE, Xfce provides a GTK+-based desktop environment that uses only about one-third the memory of GNOME. Xfce’s window manager, xfwm, was the first to include a compositing manager, which made it the first production-quality desktop with integrated support for drop shadows and transparent windows when used with the COMPOSITE extension.

All of the modern desktop environments are actually program suites, which include programs to manage the panel(s), desktop background, files, and program-launching menus; a session manager and a window manager; and a selection of panel applets and utilities including calculators, clocks, and monitors. In order to ensure that these programs function well together, inter-process communications servers, notification agents, object request brokers, and other tools get drawn into the mix. It’s not uncommon for KDE or GNOME to consume over 60 MB of memory just to start up.

On the other hand, some window managers have been extended to include program-launching and panel-management features and can serve as minimalist desktop environments. The main difference is that with window managers, most of the heavy lifting is done by a single program.

In this chapter, we’ll look at session managers (Section 8.2) and virtual desktops (Section 8.3)—both standard features in today’s desktops—and then examine the startup sequences for the following:

In each case we’ll look at how the window manager can be changed and at additional applications that start when the user logs in.

We’ll also examine how a system can be set up to use only a window manager without a full desktop environment (Section 8.7).

An X session is roughly equivalent to a character-mode login. A session manager (SM) is responsible for saving and restoring the session state; this allows the user to log out and later log in, and to find—more or less—the same programs running. The state information can include the window position, open files, cursor position, and so forth. If the session manager finds that no previous session has been saved, a default session can be started.

Session managers use the X Session Management Protocol (XSMP), which is built on top of the Inter-Client Exchange( ICE) protocol. This is distinct from the X11 protocol and uses different (and variable) ports.

At the beginning of a session, the SM starts clients that have a saved state. To enable communication with the session manager, clients are passed a connection string in the SESSION_MANAGER environment variable. This takes one of two forms, depending on whether TCP/IP or Unix domain sockets are used:

	tcp/hostname:port
	local/hostname:path

Where hostname is a suitable hostname (usually a fully qualified domain name (FQDN), but possibly a hostname within the local domain, an IP address, or an alias such as localhost), port is a TCP/IP port number, and path is the pathname of a Unix domain socket.

When an XSMP-aware client starts, it connects to the SM and introduces itself. The SM assigns a unique ID number, and the client informs the SM of the command line that will start it with the same ID number. It’s also possible for clients to ask to be restarted if they terminate unexpectedly, or to save their state and ask to be restarted in the next session even if they are not running at the end of the current session. Clients may also provide a command line that will discard the current session information, so that (for example) disk space used to store the session state will free up if the user doesn’t want to restore the session.

When a user logs out of her session (and indicates that she wants to save the session, if given the option), the SM sends a message to all registered clients to tell them to save their state. The clients can optionally communicate with the user at this point, which permits the client to ask the user for the filename under which data should be saved. When the next session starts, the SM uses the command that was specified by the client to restart it with the same ID.

Note that the session manager does not save the actual state of the client (other than the ID number). It’s up to the client to save its state. This is typically done with hidden files in the user’s home directory, but the programmer can choose another method. It’s up to the application programmer to decide how much state information is saved; some programs may save only the name of the currently open file, while others may save many details such as the window size and position, cursor position, and undo history.

KDE and GNOME each provide session managers. The standard X distribution also provides a session manager, known as xsm, but it is perhaps more of a proof-of-concept than a workable session manager for daily use.

Many of the current window managers provide virtual desktop or workspace capability—the ability to access a desktop space that is a multiple of the screen size. For example, a window manager configured with four virtual desktops would permit you to move with the mouse or keyboard from one of the four desktops to another.

Virtual desktops provide a simple, easily understood mechanism for organizing large numbers of windows. It’s not uncommon to see users group related applications on different desktops—email and messaging on one, web browsing on another, photo management or writing on a third—and then jump between them.

Most window managers or desktop environments that provide virtual desktops also provide a pager (or workspace switcher ,or desktop switcher), which permits the user to see the size and position of windows on each desktop and to switch desktops by clicking on one. Some pagers also permit you to drag windows from one virtual desktop to another.

The GNOME desktop switcher, shown in Figure 8-1, shows the typical appearance of most pagers; when this example was taken, there were 22 windows on 6 virtual desktops (some are hidden under other windows).

Figure 8-1. The GNOME desktop switcher

Resource-wise, virtual desktops are a freebie. This is because they are an illusion created by the window manager.

Studying the output of xwininfo gives the secret away. There are two different ways to create virtual desktops:

Figure 8-2 shows three virtual desktops as imagined by the user and as displayed in a pager. There are three separate application windows shown on the three desktops: kcalc, Firefox, and OpenOffice.org.

Figure 8-2. User’s view of three virtual desktops

If the user makes the center desktop current, and the window manager is using mapping to create the virtual desktop illusion, then the actual window placement will be as shown in Figure 8-3. Any window not on the current desktop is unmapped (hidden), as shown here with a dotted outline.

Figure 8-3. Actual window positions (dotted outlines represent unmapped windows)

If the window manager is instead using window positioning to create the virtual desktop illusion, the window positions will be as shown in Figure 8-4. Windows that are not on the current desktop are still mapped, but are positioned off-screen.

Figure 8-4. Actual window position created by positioning windows off-screen

When the virtual desktop illusion is created by window positions, it is possible to have the current desktop positioned between virtual desktops, so that parts of two or more virtual desktops are visible simultaneously (however, this precludes easily setting different backgrounds on each virtual desktop). It’s also possible to have windows span virtual desktops. A window manager in this system has to update the position of all of the windows when changing desktops. The fvwm2 window manager uses this approach.

If the virtual desktop illusion is created by mapping and unmapping windows, less information needs to be updated when switching desktops, and it becomes possible to set the desktop background on a per-desktop basis. This approach is used by the KDE (kwin) and GNOME ( Metacity) window managers; kwin allows the use of per- desktop background images.

Windows managed on multiple virtual desktops do not take significantly more resources than windows managed on a single desktop (unless you’re using multiple background images), but virtual desktops may encourage users to keep more applications open at one time.

GNOME is started through its session manager, gnome-session, which may be directly called from the command line if the DISPLAY variable has been set to point to a running X server:

          $ gnome-session

When started,gnome-session will look up the current session name in the ~/.gnome2/ session-options file, and then look for that session in ~/.gnome2/session. If that file can’t be found, gnome-session uses the default session in /usr/share/gnome/default.session as a system-wide default session definition.

A standard GNOME session includes these standard GNOME clients:

Other applications may also be started.

GNOME is usually used with the Metacity window manager, but it can be used with others. In order to provide some flexibility, gnome-wm is a script that can be customized to use a different window manager. You can select a specific window manager by placing its name in the WINDOW_MANAGER environment variable, or you can place line setting that variable near the top of the gnome-wm script:

          WINDOW_MANAGER=mwm

To start an X server and the GNOME desktop by hand:

          $ export DISPLAY=:1
	$ X $DISPLAY &
	$ gnome-session

You can specify a specific session name by using the --choose-session option:

          $ gnome-session --choose-session
          SessionName

Alternately, you can also specify that the default.session file be used by specifying the --failsafe option.

When the user exits from the GNOME desktop, he is presented with a dialog as shown in Figure 8-5; this dialog may have options for reboot, shutdown, or hiberna-tion in some cases. The checkbox labeled Save Current Settings controls whether the session is saved—if that box is checked, and the user clicks the OK button, then the current clients are queried using XSMP, and the session information is written to ~/.gnome2/session using the session name supplied with the --choose-session option (or default, if no name was specified). Otherwise, the contents of ~/.gnome2/ session are not disturbed.

Figure 8-5. The gnome-session logout dialog

You can edit the default session definition (/usr/share/gnome/default.session) using a standard text editor. Here is the Fedora version of default.session :

	# This is the default session that is launched if the user doesn't
	# already have a session.
	# The RestartCommand specifies the command to run from the $PATH.
	# The Priority determines the order in which the commands are started
	# (with Priority = 0 first) and defaults to 50.
	# The id provides a name that is unique within this file and passed to the
	# app as the client id which it must use to register with gnome-session.
	# The clients must be numbered from 0 to the value of num_clients - 1.


	[Default]
	num_clients=5
	0,id=default0
	0,Priority=60
	0,RestartCommand=pam-panel-icon --sm-client-id default0
	1,id=default1
	1,Priority=10
	1,RestartCommand=gnome-wm --default-wm gnome-wm --sm-client-id default1
	2,id=default2
	2,Priority=40
	2,RestartCommand=gnome-panel --sm-client-id default2
	3,id=default3
	3,Priority=40
	3,RestartCommand=nautilus --no-default-window --sm-client-id default3
	4,id=default4
	4,Priority=40
	4,RestartCommand=gnome-volume-manager --sm-client-id default4

Notice that there are five clients in this session, as indicated by the num_clients entry. These clients are numbered from 0 to 4, and the client number appears as the first comma-delimited field on each line.

The clients are started in order based on the Priority entry for each client, with lower-numbered clients going first. If the Priority is omitted, it defaults to 50. These prior-ity values are used to ensure that, for example, the window manager starts before the panel client, so that the virtual desktop switcher applet in the panel (which talks to the window manager) can initialize without any errors.

The client ID value (defaultN) is a placeholder and will be updated by the SM when the client registers with it. The id line informs gnome-session about the client ID in use; the options in the RestartCommand entry pass the same information to the client. Once the client connects to the SM, the id value is changed to a concatenation of the IP address, current time, process ID, and a sequence number. This is (in almost all cases) a globally unique identifier.

The actual command used to start each client is listed in the RestartCommand entry. It’s called the RestartCommand because the session manager is trying to restore a saved session by restarting clients that were running in a previous session.

You can easily add entries. For example, to set a system-wide default of starting Evolution when the GNOME desktop starts, append these lines to the end of the file:

          5,id=default7
	5,Priority=60
	5,RestartCommand=evolution --sm-client-id default7

You would also need to change the num_clients entry:

          num_clients=6

In order to successfully start GNOME using gnome-session when another session manager is running —for example, to start GNOME when KDE is already active (not all that useful, but interesting for testing!)—you will need to remove the SESSION_ MANAGER variable first:

          $ unset SESSION_MANAGER
	$ gnome-session

uses a very different approach to initialization. Although KDE does have a session manager, it does not start many of the KDE components. Instead, most of the startup sequence is initiated by a script named startkde (imagine that, a KDE program that doesn’t start with k!):

          $ startkde

Since startkde is a script, you can simply open it in a text editor to read or modify it.

startkde runs through a number of sanity checks, verifying that there is sufficient temporary disk space available, the home directory is writable, and so forth. Finally, it starts kdeinit, which starts a number of processes; some of these are normal binary programs, and some are KDE loadable modules ( KLMs). KLMs may load faster than traditional binaries and are typically found in /usr/lib/kde3.

These are some of the key processes:

Many of these background processes are like daemons, but are executed once per active display per logged-in user. In other words, if four users are logged into KDE desktops, and one of those users is logged in on two displays, then five copies of these background programs will be executed.

The startkde script will use a different window manager if one is defined in the KDEWM environment variable. This is useful if you’re starting KDE using startx (Section 2.9)—for example:

          $ KDEWM=mwm startx

You can also set this variable near the top of the startkde script itself. This line would specify mwm as the window manager in place of kwin:

          KDEWM=mwm

The ksmserver process in turn starts the desktop session, using three sources of information:

The /usr/share/autostart/*.desktop files are started regardless of the per-user session configuration, and these files in turn launch the foundational KDE applications including kdesktop and the KDE panel manager kicker, as well as less-critical applica-tions such as ktip (the tip-of-the-day program).

To add an additional program to the standard, system-wide startup sequence, create an additional desktop file in /usr/share/autostart/. For example, here is a minimal desktop file to start the Evolution PIM client (yes, Evolution is a GNOME applica-tion—mix ‘n’ match is one of the joys of X); this file should be saved as /usr/share/ autostart/evolution.desktop:

	 [Desktop Entry]
	 Encoding=UTF-8             # Character set used in this file
	 Name=Evolution             # Program name
	 GenericName=Evolution PIM  # Description
	 Exec=evolution             # Command to be executed
	 Icon=evolution             # Icon name
	 Type=Application           # This is an application program
	 Terminal=false             # Don't start in a terminal

If you want this client to start only for a particular user instead of for all users, then place the file in ~/.kde/Autostart/ instead of /usr/share/autostart, and kdeinit will start it instead of ksmserver.

Like GNOME, KDE will save the state of the session when the user logs out; however, the user is not given the option to avoid saving the session (unless she aborts the session, perhaps by zapping the server; see Section 2.13).

Xfce is a lightweight desktop environment based on GTK+;it is particularly well suited to systems with limited resources and to remote access (for example, through VNC; see Section 14.1). Xfce was originally built on top of the XForms toolkit (not the web specification!), which was the source of its name.

Xfce is started using the >startxfce4 script. Unlike gnome-session or startkde, the startxfce4script will attempt to start an X server—via xinit—if one isn’t already running (which it assumes is the case if the DISPLAYenvironment variable is unset):

          $ startxfce4

startxfce4 does some sanity checks and basic setup, and then starts the session manager xfce4-session.

The user’s session information is taken from ~/.cache/sessions/ if it exists; otherwise,it’s taken from the [Failsafe Session] section of /etc/xdg/xfce4-session/xfce4.rc.

Here is the default xfce4-session.rc file withthe[Failsafe Session section highlighted:

	 # $Id$: xfce4-session.rc 4690 2004-10-06 14:03:11z benny $
	 #
	 # Default xfce4-session configuration file.
	 #
	 # Copyright (c) 2003-2004 Benedikt Meurer <[email protected]>
	 # All rights reserved.
	 #
	 # This program is free software; you can redistribute it and/or modify
	 # it under the terms of the GNU General Public License as published by
	 # the Free Software Foundation; either version 2, or (at your option)
	 # any later version.
	 ...(comment lines lines snipped)...
	 
	 [General] 
	 SessionName=Default 
	 SessionName[de]=Standard
	 
	 # Disable management of remote clients by default. The user 
	 # has to explicitly enable this for security reasons. 
	 DisableTcp=True
	 
	 # This the default session launched by xfce4-session if the 
	 # user hasn't saved any session yet or creates a new session.
	 [Failsafe Session] 
	 Count=4 
	 Client0_Command=xfwm4 
	 Client0_PerScreen=False 
	 Client1_Command=xfce4-panel 
	 Client1_PerScreen=True 
	 Client2_Command=xftaskbar4

	 Client2_PerScreen=True
	 Client3_Command=xfdesktop
	 Client3_PerScreen=False
	 
	 # Default splash screen selection.
	 [Splash Screen]
	 Engine=mice

The Count entry specifies the number of clients in the session, and each client has two lines: ClientN_Command, which specifies the command line used to start the client, and ClientN_PerScreen, which specifies whether the command should be run on each screen in the display.

To change the default window manager, simply edit the Client0_Commandline:

          Client0_Command=mwm

To add additional clients to the default session, add additional Client lines:

          Client4_Command=evolution
	 Client4_PerScreen=False

Then change the Count line to reflect the new total:

          Count=5

If the user has already saved session information, you can clear it out to force a failsafe session to be used at next login:

          # rm ~user/.cache/sessions/*

Xfce gives the user the option of saving the session when the logout icon on the panel is clicked, as shown in Figure 8-6. This updates the ~/.cache/session directory.

Figure 8-6.  Xfce Session logout dialog

Sometimes a full-blown desktop environment can be overkill, particularly on a machine with limited memory or CPU resources, or when the user will be limited to a small range of tasks (such as certain kiosk [Section 15.1] designs).

Although there are dozens of window managers available, the granddaddy of them all is twm, which has been distributed with X since Release 4. twm was the first of the re-parenting window managers, which wrap each window in a larger window to add a border and title bar, and its code formed the foundation for many other window managers.

twm is still distributed with X. Most OS distributions also include additional window managers; Table 8-1 lists some common ones that are not part of a desktop environment. Remember that window managers included with desktop environments, such as kwinand Metacity, can also be used independently of those environments.

When using a window manager by itself, you need to ensure that one or more cli-ents are automatically started for the user, or that the window manager is configured with a program-launching menu. Here is a very simple script that will start an X server along with a window manager and selected clients:

	#!/bin/sh
	# Start an X server with specific clients

	# === CONFIGURATION VARIABLES

	# Display number
	NEWDISPLAY=":8"

	# X server command line (can use Xnest for testing)
	# Warning!: -ac disables access control
	XSERVER="Xnest -terminate -ac"

	# Window manager binary name (twm, mwm, etc).
	WM=mwm

	# Clients to be started, space-separated
	CLIENTS="/usr/bin/evolution /usr/local/bin/firefox"

	# === END OF CONFIGURATION VARIABLES

	unset SESSION_MANAGER

	# Start X server
	$XSERVER $NEWDISPLAY &

	# This is performed after server is started in
	# case we're using Xnest

	export DISPLAY="$NEWDISPLAY"

	# Wait for ports to be opened
	sleep 2

	# Start window manager
	$WM&

	# Start clients
	for NAME in $CLIENTS
	do
	    $NAME&
	done

Note that this script has been configured to use Xnest for testing purposes; change the XSERVER environment variable to make it start a normal hardware-driving X server:

	XSERVER="X -terminate"

Note that the X server won’t terminate until the last client dies—and the last client is usually the window manager. The default root menu for mwm, for example, includes an option to exit, which must be selected to exit the X server. If you’re building a kiosk, you can use a more robust solution (Section 15.10).

You can modify the script above to work as an ~/.xinitrc script, for use with startx (Section 2.9), if you remove the X server startup:

	 #!/bin/sh
	 # Start an X server with specific clients

	 # === CONFIGURATION VARIABLES

	 # Window manager binary name (twm, mwm, etc).
	 WM=mwm

	 # Clients to be started, space-separated
	 CLIENTS="/usr/bin/evolution /usr/local/bin/firefox"

	 # === END OF CONFIGURATION VARIABLES

	 # Start clients

	 for NAME in $CLIENTS
	 do
	     $NAME&
	 done

	 # Start window manager - server will be terminated
	 # when the window manager exits

	 $WM

Since xinit/startx will shut down the X server when the ~/.xinitrc script terminates, the last client—in this case, the window manager—should be run in the foreground (that is, without an ampersand), preventing the script from ending until you exit from the window manager.

You can test this .xinitrc using Xnest through startx (using display :8 in this example):

          $ startx -- /usr/bin/Xnest -ac :8

To start those clients on a regular X server, leave out the server binary:

	 $ startx -- :8