X Window System

History of X

The X Window System (www.x.org) was created in 1984 at the Massachusetts Institute of Technology (MIT) by researchers working on a distributed computing project and a campuswide distributed environment, called Project Athena. This system was not the first windowing software to run on a UNIX system, but it was the first to become widely available and accepted. In 1985, MIT released X (version 9) to the public, for use without a license. Three years later, a group of vendors formed the X Consortium to support the continued development of X, under the leadership of MIT. By 1998, the X Consortium had become part of the Open Group. In 2001, the Open Group released X version 11, release 6.6 (commonly called X11R6.6).

The X Window System was inspired by the ideas and features found in earlier proprietary window systems but is written to be portable and flexible. X is designed to run on a workstation, typically attached to a LAN. The designers built X with the network in mind. If you can communicate with a remote computer over a network, running an X application on that computer and sending the results to a local display are straightforward.

While the X protocol has remained stable for quite a long time, additions in the form of extensions are quite common. One of the most interesting, albeit one that has not yet made its way into production, is the Media Application Server, which aims to provide the same level of network transparency for sound and video that X does for simple windowing applications.

XFree86 and X.org

Red Hat Linux used the XFree86 X server, which inherited its license from the original MIT X server, through release 4.3. In early 2004, just before the release of XFree86 4.4, the XFree86 license was changed to one that is more restrictive and not compatible with the GPL (page 4). A number of distributions, including Red Hat Linux, abandoned XFree86 and replaced it with an X.org X server that is based on a pre-release version of XFree86 4.4, which predates change in the XFree86 license.

The X.org X server, named Xorg, is functionally equivalent to the one distributed by XFree86 because most of the code is the same. Modules designed to work with one server work with the other.

The X stack

The Linux GUI is built in layers (Figure 8-1). The bottom layer is the kernel, which provides the basic interfaces to the hardware. On top of the kernel is the X server, which is responsible for managing windows and drawing basic graphical primitives such as lines and bitmaps. Rather than directly generating X commands, most programs use Xlib, the next layer, which is a standard library for interfacing with an X server. Xlib is complicated and does not provide high-level abstractions, such as buttons and text boxes. Rather than using Xlib directly, most programs rely on a toolkit that provides high-level abstractions. Using a library not only makes programming easier, but has the added advantage of bringing consistency to applications.

Figure 8-1. The X stack

In recent years, the popularity of X has extended outside the UNIX community and beyond the workstation class of computers it was originally conceived for. Today X is available for Macintosh computers as well as for PCs running Windows. It is also available on a special kind of display terminal, known as an X terminal, developed specifically to run X.

Client/server environment

Computer networks are central to the design of X. It is possible to run an application on one computer and display the results on a screen attached to a different computer; the ease with which this can be done distinguishes X from other window systems available today. Thanks to this capability, a scientist can run and manipulate a program on a powerful supercomputer in another building or another country and view the results on a personal workstation or laptop computer. For more information refer to "Remote Computing and Local Displays" on page 237.

When you start an X Window System session, you set up a client/server environment. One process, called the X server, displays desktops and windows under X. Each application program and utility that makes a request of the X server is a client of that server. Examples of X clients include xterm, kwin, xclock, and such general applications as word processing and spreadsheet programs. A typical request from a client is to display an image or open a window.

Tip: The roles of X client and server may be counterintuitive

The terms client and server, when referring to X, have the opposite meanings of how you might think of them intuitively: The server runs the mouse, keyboard, and display; the application program is the client.

This disparity becomes even more apparent when you run an application program on a remote system. You might think of the system running the program as the server and the system providing the display as the client, but in fact it is the other way around. With X, the system providing the display is the server, and the system running the program is the client.

Events

The server also monitors keyboard and mouse actions (events) and passes them to the appropriate clients. For example, when you click the border of a window, the server sends this event to the window manager (client). Characters you type into a terminal emulation window are sent to that terminal emulator (client). The client takes appropriate action when it receives an eventfor example, making a window active or displaying the typed character on the server.

Separating the physical control of the display (the server) from the processes needing access to the display (the client) makes it possible to run the server on one computer and the client on another computer. In general, this book discusses running the X server and client applications on a single system. Refer to "Remote Computing and Local Displays" for information on using X in a distributed environment.

Optional

You can run xev (X event) by giving the command /usr/bin/xev from a terminal emulation window and then watch the information flow from the client to the server and back again. This utility opens a window with a box in it and asks the X server to send it events each time anything happens, such as moving the mouse pointer, clicking a mouse button, moving the mouse pointer into the box, typing, or resizing the window. The xev utility displays information about each event in the window that you opened it from. You can use xev as an educational tool: Start it and see how much information is being processed each time you move the mouse. Close the Event Tester window to exit from xev.

Using X

This section provides basic information about starting and configuring X from the command line.

Caution: Killing a graphical program

When you press CONTROL-ALT-ESCAPE, the mouse pointer changes into a skull and crossbones. When you move this mouse pointer over the window of a misbehaving or frozen application and click, the system kills the program that controls the window.

Use this technique with care. If you decide that you do not want to kill a program, press ESCAPE to return the mouse pointer to its normal mode. Killing the wrong program, such as the desktop, can be problematic.

Starting X from a Character-Based Display

Once you have logged in on a virtual console (page 113), you can start an X Window System server by using startx. See page 404 for information on changing the initdefault entry in the /etc/inittab file so Linux boots into character (and not graphical) mode. When you run startx, the X server displays an X screen, using the first available virtual console. The following command causes startx to run in the background so that you can switch back to this virtual console and give other commands:

$ startx &

Remote Computing and Local Displays

To identify the display that an X application is to use, you can either set a global shell variable or give a command line option.

The DISPLAY Variable

The most common method of identifying a display is to use the DISPLAY shell environment variable. This locally unique identification string is automatically set by xinit when it starts the X server.

The DISPLAY variable holds the screen number of a display:

$ echo $DISPLAY :0

The format of the complete (globally unique) ID string for a display is

[hostname]:display-number[.screen-number]

where hostname is the name of the system running the X server, display-number is the number of the logical (physical) display (0 unless multiple monitors or graphical terminals are attached to the system, or if you are running X over ssh), and screen-number is the logical number of the (virtual) terminal (0 unless you are running multiple instances of X). When you are working with a single physical screen, you can shorten the identification string. For example, you can use bravo:0.0 or bravo:0 to identify the only physical display on the system named bravo. When the X server and the X clients are running on the same system, you can shorten this identification string even further to :0.0 or :0. An ssh connection (page 583) shows DISPLAY as localhost:10.0.

If DISPLAY is empty or not set, the screen you are working from is not running X. An application (the X client) uses the value of the DISPLAY variable to determine which display, keyboard, and mouse (collectively, the X server) to use. One way to run an X application, such as xclock, on the local system but have it use the X Window System display on a remote system is to change the value of the DISPLAY variable on the local system to identify the remote X server. If you get a refused or not authorized error, refer to the tip "xhost grants access to a display" (next page).

$ export DISPLAY=bravo:0.0 $ xclock &

The preceding example starts xclock with the default X server running on the system named bravo. After setting the DISPLAY variable to the ID of the bravo server, all X programs (clients) you start will use bravo as their server (output appears on bravo's display and input comes from bravo's keyboard and mouse).

Tip: When you change the value of DISPLAY

When you change the value of the DISPLAY variable, all X programs send their output to the display named by DISPLAY.

The display Option

To override the default X server, you can specify the display (and keyboard and mouse) you want to use on the command line:

$ xclock -display bravo:0.0

Many X programs accept the display option, which affects just the command you use it with. All other X-related commands will send their output to the display specified by the DISPLAY variable.

Tip: xhost grants access to a display

If the system displays an error message when you try to open a window on a remote display, the remote user needs to run xhost to grant you access to that display. For example, if you are logged in on a system named kudos and you want to create a window on Alex's display, Alex needs to run the following command:

$ xhost +kudos

If Alex wants to allow anyone to create windows on his display, he can give the following command, which grants access to all systems:

$ xhost +

If you frequently work with other users via a network, you may find it convenient to add an xhost line to your .bash_profile file (page 267). Be selective in granting access to your X display with xhost, however; if another system has access to your display, you may find that your work is interrupted all too often.

Security: Security and xhost

Allowing a remote system access to your display using xhost means that any user on the remote system can watch everything you type in a terminal emulation window, including passwords. For this reason, some software packages, such as the Tcl/Tk development system (www.tcl.tk), restrict their own capabilities when xhost is used. If you are concerned about security or want to take full advantage of systems such as Tcl/Tk, you should use a safer means of granting remote access to your X session. See the xauth man page for information about a more secure replacement for xhost.

Running Multiple X Servers

You can start multiple X servers on a single system. The most common reason for starting a second X server is to use a second display that allocates a different number of bits to each screen pixel. The possible values are 8, 16, 24, and 32 bits per pixel. Most X servers available for Linux default to 24 or 32 bits per pixel, permitting the use of millions of colors simultaneously. Starting an X server with 8 bits per pixel permits the use of any combination of 256 colors at the same time. The maximum number of bits per pixel allowed depends on the computer graphics hardware and X server. With fewer bits per pixel, the system has to transfer less data, possibly making it more responsive. In addition, many games work with only 256 colors.

When you start multiple X servers, each must have a different ID string. The following command starts a second X server; do not give this command from a terminal emulator:

$ startx -- :1

The option marks the end of the startx options and arguments. Arguments to the left of this option belong to startx. The startx script passes arguments that appear to the right of this option to the X server. The following command starts an X server running at 16 bits per pixel: The following command starts a second X server running at 16 bits per pixel:

$ startx -- -depth 16 &

Refer to "Using Virtual Consoles" on page 113 for information on how to switch to a virtual console to start a second server.

KDE

FEDORA Under KDE you can select Main menu: Switch User Start a New Session to start another X server.

X over ssh

See "Tunneling/Port Forwarding" on page 596 for information about running X over an ssh connection.

Stopping the X Server

How you terminate a window manager depends on which window manager you are running and how it is configured. If X stops responding, switch to a virtual terminal, log in from another terminal or a remote system, or use ssh to gain access to the system. Then kill (page 395) the process running Xorg. You can also press CONTROL-ALT-BACKSPACE to quit the X server. This method may not shut down the X session cleanly, however, so it should be used only as a last resort.

Remapping Mouse Buttons

Throughout this book, each description of a mouse click refers to the button by its position (left, middle, or right, with left implied when no button is specified) because the position of a mouse button is more intuitive than an arbitrary name or number. X terminology numbers buttons starting at the left and continuing with the mouse wheel. The buttons on a three-button mouse are numbered 1 (left), 2 (middle), and 3 (right). A mouse wheel, if present, is 4 (rolling it up) and 5 (rolling it down). Clicking the wheel is equivalent to clicking the middle mouse button. The buttons on a two-button mouse are 1 (left) and 2 (right).

If you are right-handed, you can conveniently press the left mouse button with your index finger; X programs take advantage of this fact by relying on button 1 for the most common operations. If you are left-handed, your index finger rests most conveniently on button 2 or 3 (the right button on a two- or three-button mouse).

To exchange the functions of the left and right mouse buttons when you are running GNOME, from the panel at the top of the window select System: Preferences Mouse (RHEL uses Applications: Preferences Mouse) and put a check mark in the box labeled Left-handed mouse. From KDE choose Main menu: Control Center Peripherals Mouse and select Left handed from the General tab.

You can also change how X interprets the mouse buttons by using xmodmap. If you are left-handed and using a three-button mouse with a wheel, the following command causes X to interpret the right button as button 1 and the left button as button 3:

$ xmodmap -e 'pointer = 3 2 1 4 5'

Omit the 4 and 5 if the mouse does not have a wheel. The following command works for a two-button mouse without a wheel:

$ xmodmap -e 'pointer = 2 1'

If xmodmap displays an error message complaining about the number of buttons, use the pp option to xmodmap to display the number of buttons that X has defined for the mouse:

$ xmodmap -pp There are 9 pointer buttons defined.     Physical        Button      Button          Code         1               1         2               2         3               3         4               4         5               5         6               6         7               7         8               8         9               9

Then expand the previous command, adding numbers to complete the list. If the pp option shows nine buttons, give the following command:

$ xmodmap -e 'pointer = 3 2 1 4 5 6 7 8 9'

Changing the order of the first three buttons is critical to making the mouse suitable for a left-handed user. When you remap the mouse buttons, remember to reinterpret the descriptions in this book accordingly. When this book asks you to click the left button, or does not specify a button to click, use the right button, and vice versa.

Window Managers

Conceptually X is very simple and does not provide some of the more common features found in GUIs, such as the ability to drag windows. The UNIX/Linux philosophy is one of modularity: X relies on a window manager, such as Metacity or kwin, to draw window borders and handle moving and resizing operations.

Unlike a window manager, which has a clearly defined task, a desktop environment (manager) does many things. In general, a desktop environment, such as KDE or GNOME, provides a means of launching applications and utilities, such as a file manager, that a window manager can use.

KDE and GNOME

The KDE project began in 1996, with the aim of creating a consistent, user-friendly desktop environment for free UNIX-like operating systems. KDE is based on the Qt toolkit made by Trolltech. When KDE development began, the Qt license was not compatible with the GPL (page 4). For this reason the Free Software Foundation decided to support a different project, the GNU Network Object Model Environment (GNOME). More recently Qt has been released under the terms of the GPL, removing part of the rationale for GNOME's existence.

KDE

KDE is written in C++ on top of the Qt framework. KDE tries to use existing technology, if it can be reused, but creates its own if nothing else is available or a superior solution is needed. For example, KDE implemented an HTML rendering engine long before the Mozilla project was born. Similarly, work on KOffice began a long time before StarOffice became the open-source OpenOffice. In contrast, the GNOME office applications are stand-alone programs that originated outside the GNOME project. The GNOME Web browser uses the HTML rendering engine developed by the Mozilla project.

KDE's portability was recently demonstrated when a version of most of the core components, including Konqueror and KOffice, was released for Mac OS X.

KParts

By itself, Konqueror has very little functionality; this application uses other applications to do all its work. Konqueror takes advantage of KDE i/o slaves and components (KParts). The i/o slaves accept or gather input and change it to a standard format that a component can display. When you open Konqueror to view your home directory, Konqueror calls the File i/o slave, which gathers information about the filesystem and uses the Icon view component (Konqueror menubar: View View Mode Icon View) or the Text view component (Konqueror menubar: View View Mode Text View) to display the information it gets from the File i/o slave.

The i/o slaves are discrete modules; it is relatively easy to write a new one. Konqueror uses an i/o slave automatically when you put it in the directory structure ($KDEDIR/lib/kde3/kio_protocol.* and $KDEDIR/share/services/protocol.desktop, where $KDEDIR is /usr by default and protocol is the name of the protocol). Examples of i/o slaves and their output format include FTP (virtual filesystem), POP3 (each retrieved piece of email appears as a file), and the audio CD browser (kio_audiocd; each track appears as a file).

The components display the information they receive from the i/o slaves. One i/o slave can feed several different components, and one component can receive input from several different i/o slaves. Both an i/o slave and a component pair must be available to display information within a Konqueror view.

GNOME

GNOME is the default desktop environment for Red Hat Linux. It provides a simple, coherent user interface suitable for corporate use. GNOME uses GTK for drawing widgets. GTK, developed for the GNU Image Manipulation Program (gimp), is written in C, although bindings for C++ and other languages are available.

GNOME does not take much advantage of its component architecture. Instead, it continues to support the traditional UNIX philosophy of having many small programs, each of which is good at doing a specific task.

Interoperability

Since version 2, GNOME has focused on simplifying its user interface, removing options where they are deemed unnecessary, and aiming for a set of default settings that the end user will not wish to change. KDE has moved in the opposite direction, emphasizing configurability.

The freedesktop.org group (freedesktop.org), whose members are drawn from the GNOME and KDE projects, is improving interoperability and aims to produce standards that will allow the two environments to work together. One standard released by freedesktop.org allows applications to use the notification area of either the GNOME or KDE panel without being aware of which desktop environment they are running in.

GNUStep

The GNUStep project (www.gnustep.org), which began before both the KDE and GNOME projects, is creating an open-source implementation of the OPENSTEP API and desktop environment. The result is a very clean, fast user interface.

The default look of WindowMaker, the GNUStep window manager, is somewhat dated, but theme support is currently in beta. The user interface is widely regarded as one of the most intuitive of any UNIX platform. GNUStep has less overhead than KDE and GNOME, so it runs better on older hardware. If you are running Linux on hardware that struggles with GNOME and KDE or you would like to try a user interface that does not try to mimic Windows, try GNUStep. WindowMaker is provided in the WindowMaker package.