Skip to main content

By clicking Submit, you agree to the developerWorks terms of use.

The first time you sign into developerWorks, a profile is created for you. Select information in your profile (name, country/region, and company) is displayed to the public and will accompany any content you post. You may update your IBM account at any time.

All information submitted is secure.

  • Close [x]

The first time you sign in to developerWorks, a profile is created for you, so you need to choose a display name. Your display name accompanies the content you post on developerworks.

Please choose a display name between 3-31 characters. Your display name must be unique in the developerWorks community and should not be your email address for privacy reasons.

By clicking Submit, you agree to the developerWorks terms of use.

All information submitted is secure.

  • Close [x]

developerWorks Community:

  • Close [x]

LPI exam 101 prep: The X Window System

Junior Level Administration (LPIC-1) topic 110

Ian Shields, Senior Programmer, IBM
Ian Shields
Ian Shields works on a multitude of Linux projects for the developerWorks Linux zone. He is a Senior Programmer at IBM at the Research Triangle Park, NC. He joined IBM in Canberra, Australia, as a Systems Engineer in 1973, and has since worked on communications systems and pervasive computing in Montreal, Canada, and RTP, NC. He has several patents and has published several papers. His undergraduate degree is in pure mathematics and philosophy from the Australian National University. He has an M.S. and Ph.D. in computer science from North Carolina State University. You can contact Ian at
(An IBM developerWorks Contributing Author)

Summary:  In this tutorial, Ian Shields continues preparing you to take the Linux Professional Institute® Junior Level Administration (LPIC-1) Exam 101. In this fifth in a series of five tutorials, Ian introduces you to the X Window System on Linux®. By the end of this tutorial, you will know how to install and maintain the X Window System. This tutorial covers both major packages for X on Linux: XFree86 and X.Org.

View more content in this series

Date:  02 Jul 2006
Level:  Intermediate PDF:  A4 and Letter (560 KB | 32 pages)Get Adobe® Reader®

Activity:  25114 views

Customize a window manager

This section covers material for topic 1.110.4 for the Junior Level Administration (LPIC-1) exam 101. The topic has a weight of 5.

In this section, you learn how to:

  • Customize a system-wide desktop environment or window manager
  • Customize window manager menus and desktop panel menus
  • Configure an X terminal
  • Verify and resolve library dependency issues for X applications
  • Export an X display

Window managers

In the previous section, you learned about display managers and how to set them up. You also learned in this tutorial that while X is a toolkit enabling applications to create graphical windows, it does not specify a user interface. In this section, you learn more about user interfaces and how to configure what happens after you have an X session up and running.

You can imagine that, without any user interface specification, developer creativity might result in many different styles of windows, all vying for space on your screen, and all with different keystrokes, mouse operations, and styles for things like buttons, dialog boxes, and so on. To bring some order to chaos, higher level toolkits were developed. These in turn gave rise to window managers, such as twm, fvwm, and fvwm2 and finally to desktops such as KDE and GNOME.

Desktops provide a consistent user experience but also consume considerable CPU and memory resources. Before computers had the power to support the likes of a KDE or GNOME desktop, window managers were popular, and many users still like them for their light weight and fast response.

If you have just installed X and you type in the command startx, then you will see a display something like Figure 5.

Figure 5. Running twm with startx
Modifying GDM configuration with gdmsetup

This is the twm window manager, shown with the menu that is obtained by pressing mouse button 1 (normally the left button for right-handed users) over the background. You will notice three terminal windows and an analog clock, but no task bars, launchers, or other desktop paraphernalia.

The startx command is actually a front end command to xinit, which starts the X server process and some client applications. It is usually located in /usr/X11R6/bin, as is xinit and many other X utilities. X applications can take settings from an X resources database as well as a command line. Table 6 summarizes the names and purpose of each of the configuration files used by either startx or xinit. Note that some or all of these files may not be present on a particular system or user home directory.

Table 6. Configuration files for startx and xinit
$HOME/.xinitrcUser-defined executable script that merges in resource files and starts client applications
$HOME/.xserverrcUser-defined executable script that provides overrides for default X server configuration
/usr/X11R6/lib/X11/xinit/xinitrcSystem default executable script that merges in resource files and starts client applications
/usr/X11R6/lib/X11/xinit/xserverrcSystem default executable script that provides overrides for default X server configuration
$HOME/.XresourcesUser-defined file describing resources for X applications
$HOME/.XmodmapUser-defined file defining keyboard and mouse settings
/usr/X11R6/lib/X11/xinit/.XresourcesSystem default file describing resources for X applications
/usr/X11R6/lib/X11/xinit/.XmodmapSystem default file defining keyboard and mouse settings

Note carefully that the system xinitrc and xserverrc file omit the leading dot, while all the others have it.

Every window on a screen, and indeed every widget on the screen, has attributes such as height, width, and placement (geometry), foreground and background colors or images, title text and color, and so on. For a new client application, most of these values can be supplied on the command line. Since there are many attributes, it is easier to have defaults. Such defaults are stored in a resource database, which is built from resource files using the xrdb command.

Listing 19 shows the default xinit file shipped with XFree86 4.5.0.

Listing 19. Sample xinit file - /usr/X11R6/lib/X11/xinit/xinitrc
# $Xorg: xinitrc.cpp,v 1.3 2000/08/17 19:54:30 cpqbld Exp $


# merge in defaults and keymaps

if [ -f $sysresources ]; then
    xrdb -merge $sysresources

if [ -f $sysmodmap ]; then
    xmodmap $sysmodmap

if [ -f $userresources ]; then
    xrdb -merge $userresources

if [ -f $usermodmap ]; then
    xmodmap $usermodmap

# start some nice programs

twm &
xclock -geometry 50x50-1+1 &
xterm -geometry 80x50+494+51 &
xterm -geometry 80x20+494-0 &
exec xterm -geometry 80x66+0+0 -name login

Note that the xrdbcommand is used to merge in the resources, and the xmodmap is used to update the keyboard and mouse definitions. Finally, several programs are started in the background with a final program started in the foreground using the exec command, which terminates the current script (xinitrc) and transfers control to the xterm window with geometry 80x66+0+0 . This is the login window, and terminating it will terminate the X server. There must be one such application, although some people prefer the window manager (twm in this example) to have this role. All other applications should be started in the background so the script can complete.

The first two values in the geometry specification define the size of the window. For a clock, this is in pixels, while for the xterm windows, it is in lines and columns. If present, the next two values define the placement of the window. If the first value is positive, the window is placed relative to the left edge of the screen, while a negative value causes placement relative to the right edge. Similarly, positive and negative second values refer to the top and bottom of the screen respectively.

Suppose you want your clock to be larger with a different colored face and to be located in the bottom right of the screen instead of the top right. If you just want this for one user, copy the above file to the user's home directory as .xinitrc (remember the dot) and edit the clock specification as shown in Listing 20. You can find all the color names in the rgb.txt file in your X installation directory tree (for example, /usr/X11R6/lib/X11/rgb.txt).

Listing 20. Modifying xclock startup in xinitrc
xclock -background mistyrose -geometry 100x100-1-1 &

If you want to update the defaults for the whole installation, you should update the /usr/X11R6/lib/X11/xinit/.Xresources and /usr/X11R6/lib/X11/xinit/.Xmodmap files instead of the dot versions for individual users.

Several tools can help you customize windows and keystrokes.

Merges resources from a resource file into the X resource database for the running X server. By default it passes the source resource file through a C++ compiler. Specify the -nocpp option if you do not have a compiler installed.
Sets keyboard and mouse bindings. For example, you can switch settings for left-handed mouse usage, or set up the backspace and delete keys to work the way you are accustomed to.
Tells you information about a window, including geometry information.
Lets you customize the resources for windows on your screen, see the changes, and save them in a file that you can later use with xrdb.
Starts a window and captures X events that are displayed in the originating xterm window. Use this to help determine the appropriate codes to use when customizing keyboards or checking mouse events.

Use the man pages to find out more about each of these commands.

Figure 6 shows a busy screen with several of these commands running.

  • The upper left terminal window (the login window) is using xwd to capture the whole screen to a file.
  • The window overlapping it is running editres to modify the resources for the clock window.
  • The small central window is running xev, and the output is going to the terminal window below. The right-hand window shows the output of xwininfo for the root window (the whole screen).
  • The customized clock with its face colored mistyrose is running in the bottom right corner of the screen.

Figure 6. Window information and configuration
Window information and configuration

Besides the windows themselves, the window manager also allows customization. For example, the menu that was shown in Figure 5 is configured in a twm customization file. The system default is in the X installation directory tree (/usr/X11R6/lib/X11/twm/system.twmrc), and individual users may have a .twmrc file. If a user has multiple displays, there can be files (such as .twmrc.0 or .twmrc.1) for each display number. Listing 21 shows the part of the system.twmrc file that defines the menu shown in Figure 5.

Listing 21. Menu configuration in twm
menu "defops"
"Twm"   f.title
"Iconify"       f.iconify
"Resize"        f.resize
"Move"          f.move
"Raise"         f.raise
"Lower"         f.lower
""              f.nop
"Focus"         f.focus
"Unfocus"       f.unfocus
"Show Iconmgr"  f.showiconmgr
"Hide Iconmgr"  f.hideiconmgr
""              f.nop
"Xterm"         f.exec "exec xterm &"
""              f.nop
"Kill"          f.destroy
"Delete"        f.delete
""              f.nop
"Restart"       f.restart
"Exit"          f.quit

See the man page for twm or your preferred window manager for more information.


If you are using a display manager or desktop, you will find that these also can be configured. Indeed, you already saw the Xsetup_0 file for XDM in the previous section. As with the window manager configuration that you have just seen, desktop configuration can be done system-wide or per-user.

GNOME customization

GNOME is configured mostly using XML files. System defaults are found in directories in the /etc filesystem, such as /etc/gconf, /etc/gnome, and /etc/gnome-vfs2..0, along with other directories for specific GNOME applications. User configuration is usually found in subdirectories of the home directory that start with .g. Listing 22 shows several of the possible locations for GNOME configuration information.

Listing 22. GNOME configuration locations
[ian@lyrebird ian]$ ls -d /etc/g[cn]*
/etc/gconf  /etc/gnome  /etc/gnome-vfs-2.0  /etc/gnome-vfs-mime-magic
[ian@lyrebird ian]$ find . -maxdepth 1 -type d -name ".g[nc]*"

Rather than extensive man pages, GNOME has an online manual; you can access the manual from the gnome-help command, or from a menu item such as Desktop > Help. As of this writing, the manual has three major sections: Desktop, Applications, and Other Documentation. The table of contents for a recent version of the Desktop Help is shown in Figure 7.

Figure 7. Window information and configuration
Window information and configuration

You will find information about configuration tools under the System Administration Guide in the Desktop section and also under the Configuration Editor Manual in the applications topic in the Desktop section.

You may launch the graphical configuration editor using the gconf-editor command or by selecting Configuration Editor from the Applications > System Tools menu. The configuration for the gnome-terminal application is shown in Figure 8.

Figure 8. Window information and configuration
Window information and configuration

In addition to graphical tools, there is also a gconftool-2 command line program for interrogating and updating GNOME configuration information. See the above mentioned System Administration Guide for more details.

KDE customization

KDE is configured using plain text files with UTF-8 encoding for non-ASCII characters. As with GNOME, there may be many different configuration files. If multiple identically named files exist in different parts of the configuration tree, then the values from these are merged. Sy6stem values are located in the $KDEDIR/share/config tree, where $KDEDIR might be /etc/kde3/kdm/ or perhaps somewhere else. For example, on a SUSE SLES8 system, this is located in /etc/opt/kde3/share/config. User-specific customizations are located in the .kde/share tree in the user's home directory.

Configuration files have one or more group names enclosed in square brackets, followed by key and value pairs. The key may contain spaces and is separated from the value by an equal sign. The configuration file for the konqueror browser is shown in Listing 23.

Listing 23. KDE configuration file for konqueror browser
[HTML Settings]

[Java/JavaScript Settings]



The configuration files may be edited manually. Most systems will include a graphical editing tool, such as KConfigEditor or a tool customized for the distribution, such as the SUSE Control Center.

Different xterms

The usual xterm program that is installed with graphical desktops is very functional, but also uses quite a lot of system resource. If you are running a system with many X terminal clients running on a single processor, you may want to consider using a lighter-weight terminal. Two such are rxvt and aterm (which was built on top of rxvt). These are VT102 emulators, which are not usually installed by default, so you will need to install them.

Required libraries

By now you may be realizing that there are many different libraries and toolkits that are used for X applications. So how do you ensure that you have the right libraries? The ldd command lists library dependencies for any application. In its simplest form, it takes the name of an executable and prints out the libraries required to run the program. Note that ldd does not automatically search your PATH, so you usually need to give the path (relative or absolute) as well as the program name, unless the program is in the current directory. Listing 24 shows the library dependencies for the three terminal emulators that you saw above. The number of library dependencies for each gives you a clue about the relative system requirements of each.

Listing 24. Library dependencies for xterm, aterm, and rxvt
    root@pinguino:~# ldd `which xterm` =>  (0xffffe000) => /usr/X11R6/lib/ (0xb7fab000) => /usr/X11R6/lib/ (0xb7f88000) => /usr/X11R6/lib/ (0xb7f22000) => /usr/X11R6/lib/ (0xb7f06000) => /usr/X11R6/lib/ (0xb7eff000) => /usr/X11R6/lib/ (0xb7ead000) => /usr/X11R6/lib/ (0xb7e99000) => /usr/X11R6/lib/ (0xb7e4f000) => /usr/X11R6/lib/ (0xb7e46000) => /usr/X11R6/lib/ (0xb7e30000) => /usr/X11R6/lib/ (0xb7e22000) => /usr/X11R6/lib/ (0xb7e15000) => /usr/X11R6/lib/ (0xb7d56000) => /lib/ (0xb7d15000) => /lib/tls/i686/cmov/ (0xb7be6000) => /lib/tls/i686/cmov/ (0xb7be3000)
        /lib/ (0xb7fc3000)
root@pinguino:~# ldd `which aterm` =>  (0xffffe000) => /usr/X11R6/lib/ (0xb7f81000) => /usr/X11R6/lib/ (0xb7ec1000) => /usr/X11R6/lib/ (0xb7eb9000) => /usr/X11R6/lib/ (0xb7ea3000) => /lib/tls/i686/cmov/ (0xb7d75000) => /lib/tls/i686/cmov/ (0xb7d72000)
        /lib/ (0x80000000)
root@pinguino:~# ldd `which rxvt` =>  (0xffffe000) => /usr/X11R6/lib/ (0xb7eb0000) => /lib/tls/i686/cmov/ (0xb7d81000) => /lib/tls/i686/cmov/ (0xb7d7e000)
        /lib/ (0x80000000)

Exporting a display

An X display is known by a name of the form hostname:displaynumber.screennumber. For Linux running on a workstation such as a PC, there is typically only one display with a single screen. In this case, the displayname may be, and usually is, omitted so the display is known as :0.0. The DISPLAY environment variable is usually set to the display name., so you can display it using the command echo $DISPLAY. Depending on your system, this variable may or may not be set if you use su - to switch to another user. In such a case, you may need to set and export the DISPLAY as shown in Listing 25. In this listing you see an attempt to start the xclock application after switching to root, but the attempt fails because the DISPLAY environment variable is not set. Even if the DISPLAY variable is set, you still may not be able to use the display, as you will also need authorization to do so.

Listing 25. Attempting to start xclock
ian@lyrebird:~> whoami
ian@lyrebird:~> echo $DISPLAY
ian@lyrebird:~> su -
lyrebird:~ # echo $DISPLAY

lyrebird:~ # xclock
Error: Can't open display:
lyrebird:~ # export DISPLAY=:0.0
lyrebird:~ # echo $DISPLAY
lyrebird:~ # xclock
Xlib: connection to ":0.0" refused by server
Xlib: No protocol specified

Error: Can't open display: :0.0
lyrebird:~ # export XAUTHORITY=~ian/.Xauthority
lyrebird:~ # xclock
lyrebird:~ # ls -l ~ian/.Xauthority
-rw-------  1 ian users 206 Feb 18 16:20 /home/ian/.Xauthority

Let's take a look at what is going on here. In this case, the user ian logged in to the system and his DISPLAY environment was set to :0.0 as we expect. When user ian switched to user root, the DISPLAY environment variable was not set, and an attempt to start xclock failed because the application did not know what display to use.

So the substituted user, root, set the DISPLAY environment variable, and exported it so that it would be available to other shells that might be started from this terminal window. Note that setting and exporting an environment variable does not use the leading $ sign, while displaying or otherwise using the value does. Note too, that if the su command had omitted the - (minus) sign, the DISPLAY environment variable would have been set as it had been for user ian. Nevertheless, even with the environment variable set, xclock still failed.

The reason for the second failure lies in the client/server nature of X. Although root is running in a window on the one and only display on this system, the display is actually owned by the user who logged in originally, ian in this case. Let's take a look at X authorization.

Authorization methods

For local displays on Linux systems, authorization usually depends on a so-called MIT-MAGIC-COOKIE-1, which is usually regenerated every time the X server restarts. A user can extract the magic cookie from the .Xauthority file in his or her home directory (using the xauth extract command and give it to another user to merge into that user's .Xauthority file using the xauth merge command. Alternatively, a user can grant authority for other users to access the local system using the xhost +local: command.


Another alternative is to set the XAUTHORITY environment variable to the location of a file containing the appropriate MIT-MAGIC-COOKIE-1. When switching to root, it is easy to do this, since root can read files owned by other users. This is, in fact, what we did in Listing 25, so after setting and exporting XAUTHORITY to ~ian/.Xauthority, root is now able to open graphical windows on the desktop. We said we'd mention a difference with Red Hat systems. Using su to switch to root on a Red Hat system is slightly different on a SUSE system, where the display setup is done automatically for you.

So what if you switch to another non-root user? You will notice from Listing 25 that the .Xauthority file for user ian allows only user read and write access. Even members of the same group cannot read it, which is what you want unless you'd like someone to open up an application that takes over your screen and prevents you from doing anything! So, if you do extract an MIT-MAGIC-COOKIE-1 from your .Xauthority file, then you have to find some secure way to give it to your friendly non-root user. Another approach is to use the xhost command to grant authority to any user on a particular host.

The xhost command

Because of the difficulty of securely passing an MIT-MAGIC-COOKIE-1 cookie to another user, you may find that, for a Linux system with a single user, xhost is easier to use, even though the xauth approach is generally preferred over the xhost command, However, keep in mind the network heritage of the X Window System so that you do not accidentally grant more access than you intended and thereby open up your system and allow arbitrary network users to open windows on your desktop.

To give all local users authority to open applications on the display (:0.0), user ian can use the xhost command. Open a terminal window on your desktop and enter this command:

xhost +local:

Note the trailing colon (:). This will allow other users on the same system to connect to the X server and open windows. Since you are a single-user system, this means that you can su to an arbitrary non-root user and can now launch xclock or other X applications.

You may also use xhost to authorize remote hosts. This is generally not a good idea except on restricted networks. You will also need to enable the appropriate ports on your firewall if you are using one.

Another alternative for using X applications from another system is to connect to the system using a secure shell (ssh) connection. If your default ssh client configuration does not enable X forwarding, you may need to add the -X parameter to your ssh command. The ssh server will also need to have X forwarding enabled. In general, this is a much more secure method of using X remotely than opening up your system to arbitrary connections using xhost.

For more details on using the xauth and xhost commands, you can use the commands info xauth, man xauth, info xhost, or man xhost as appropriate to view the online manual pages. If you are interested in security for X connections, start with the manual pages for Xsecure.

4 of 6 | Previous | Next


Zone=Linux, Open source
TutorialTitle=LPI exam 101 prep: The X Window System