 |  |
Basics of X Customization
The fvwm Window Manager
The K Desktop Environment
X Applications
In the last chapter, you learned how to set up the X Window System so that it recognizes your graphics board and your monitor. While this is clearly necessary, it is of course only one half of the story. In this chapter, we will tell you the other half: customizing your X environment. Unlike the hardware setup that you normally do only once for a particular computer, you might want to change your work environment from time to time because your work habits have changed, because new and better environments are available, or simply because the old one has become boring for you. Some of these environments are quite sophisticated. For examples they let you start up a program with all the options you want at the press of a key or the click of a mouse, they let you drag file icons onto a printer to have text printed, and they can do lots of other fancy things.
Today, many distributions more or less automatically configure your X server for you and put you into a graphical environment from the start. However, if things go wrong during installation and you want to fine-tune your X server (in order to achieve a higher resolution, for example) or if you simply want to use another windowing environment than the one your distribution vendor has selected as the default, we'll tell you what to do.
We will first tell you the basics of configuring X, including what happens at startup, what X resources are, and how you can use them. In principle, this is already enough to configure X for use, but if you are anything more than a Spartan, you demand more from your work environment. We will therefore tell you how to configure a work environment based on the fvwm window manager first. For a long time, fvwm was the favorite window manager among Linux users, and only recently other window managers and desktop environments have taken the lead.
Until recently, the problem with using X on Unix systems in general and Linux in particular was that nothing was integrated. You would use a window manager and a number of X applications, but they would all look different, behave differently, and operate in a manner that was not integrated. For example, drag-and-drop-- ubiquitous on Windows or the Macintosh--was hardly heard of on Linux, and if it was, it was difficult to find two applications that could interact together with drag-and-drop.
A relatively new category of software, the so-called desktop environments, has accepted the challenge to produce a state-of-the-art Unix GUI and tries to provide an integrated, consistent desktop where all programs have the same look-and-feel, behave the same, and even provide the same menus in all applications (to the extent where this is possible).
Currently, there are two main desktop environments available for Linux, the K Desktop Environment and GNOME. KDE is a little bit older and much more advanced with respect to functionality and stability. It aims at making people coming from other computing environments feel at home, as well as providing long-term Unix users a more productive and friendly work-environment. GNOME, on the other hand, has put a lot of work into the visual aspects of a desktop environment with colorful icons and the like, but it is still lacking stability and a number of features. Therefore, we will cover KDE here.
The Red Hat, SuSE, and Caldera releases include both KDE and GNOME, while Debian includes only GNOME. You can also find more about GNOME at http://www.gnome.org. Appendix B reprints an article describing the design of that desktop.
Before running X applications, it's a good idea to learn the rudiments of X customization, so that you're not forced to live with the (often unappealing) default configuration used on many systems.
You run X with the startx command. This is a frontend (passing in reasonable options) for xinit, the program responsible for starting the X server and running various X clients that you specify. xinit (via startx) executes the shell script .xinitrc in your home directory. This script merely contains commands that you wish to run when starting X, such as xterm, xclock, and so on. If you don't have a .xinitrc file, the system default /usr/lib/X11/xinit/xinitrc is used instead.
Here, we'll present a sample .xinitrc file and explain what it does. You could use this as your own .xinitrc or copy the system default xinitrc as a starting point:
1 #!/bin/sh 2 # Sample .xinitrc shell script 3 4 # Start xterms 5 xterm -geometry 80x40+10+100 -fg black -bg white & 6 xterm -geometry -20+10 -fn 7x13bold -fg darkslategray -bg white & 7 xterm -geometry -20-30 -fn 7x13bold -fg black -bg white & 8 9 # Other useful X clients 10 oclock -geometry 70x70+5+5 & 11 xload -geometry 85x60+85+5 & 12 xbiff -geometry +200+5 & 13 xsetroot -solid darkslateblue & 14 15 # Start the window manager 16 exec fvwm2
This should be quite straightforward, even if you're not familiar with X. The first two lines simply identify the shell script. Lines 5-7 start up three xterm clients (recall that xterm is a terminal-emulator client). Other clients are started on lines 10-13, and on line 16 the window manager, fvwm, is started.
Running startx with this particular .xinitrc in place gives you something that looks like Figure 11-1.[43]
[43]All right, so it's not a work of art, but we needed something simple that would work correctly on most displays!
Let's look at this in more detail. On line 5, we see that xterm is started with several options, -geometry, -fg, and -bg. Most X clients support these standard options, among others.
The -geometry option allows you to specify the size and position of the window on the display. The geometry specification has the format:
In this case, the option -geometry 80x40+10+100 puts the window at the location (10,100) on the screen (where (0,0) is the top-left corner), making it 80 characters wide by 40 characters high. Note that xterm measures the size of the window in characters, not pixels. The actual size of the window in pixels is determined by the font that is used.xsizexysize+xoffset+yoffset
The -fg and -bg arguments allow you to specify the foreground (text) and background colors for the xterm window, respectively. The colors used here are a rather boring black and white, but this should work on color and monochrome displays alike. Under X, colors are usually specified by name, although you can provide your own RGB values if you prefer. The list of color names (and corresponding RGB values) is given in the file /usr/lib/X11/rgb.txt. Running xcolors will display these colors, along with their names.
Line 6 runs another xterm, although the arguments are slightly different:
First of all, the geometry specification is just -20+10. Without size parameters, xterm will use the default, which is usually 80x25. Also, we see that the xoffset is prefixed with a -, instead of +. This places the window 20 pixels from the right edge of the screen. Likewise, a geometry specification of -20-30 (as used on line 7) means to place the window 20 pixels from the right edge of the screen and 30 pixels from the bottom. In this way, the placement of windows is less dependent on the particular resolution you're using.xterm -geometry -20+10 -fn 7x13bold -fg darkslategray -bg white &
The -fn option on lines 6 and 7 specifies that the font used by xterm should be 7x13bold. Using the command xlsfonts displays a complete list of fonts on your system; the X client xfontsel allows you to select fonts interactively--more about fonts later.
On line 10 we start an oclock client, which is a simple analog clock. Line 11 starts xload, which displays a graph of the system load average (number of running processes) that changes with time. Line 12 starts xbiff, which just lets you know when mail is waiting to be read. Finally, on line 13 we do away with the bland grey X background and replace it with a flashy darkslateblue. (Fear not; there is more fun to be had with X decor than this example shows.)
You'll notice that each of the X clients started on lines 6-13 is executed in the background (the ampersand on the end of each line forces this). If you forget to put each client in the background, xinit executes the first xterm, waits for it to exit (usually, after you log out), executes the next xterm, and so on. The ampersands cause each client to start up concurrently.
What about line 16? Here, we start fvwm (Version 2), a window manager used on many Linux systems. As mentioned before, the window manager is responsible for decorating the windows, allowing you to place them with the mouse, and so forth. However, it is started with the command:
This causes the fvwm2 process to replace the xinit process. This way, once you kill fvwm,[44] the X server shuts down. This is equivalent to, but more succinct than, using the Ctrl-Alt-Backspace key combination.exec fvwm2
[44]If you have experimented with fvwm, you'll notice that pressing the first mouse button while the cursor is on the background causes a menu to pop up. Selecting the Quit fvwm option from this menu causes fvwm to exit.
In general, you should put an ampersand after each X client started from .xinitrc, and exec the window manager at the end of the file. Of course, there are other ways of doing this, but many users employ this technique.
If you read the manual pages for xterm and the other X clients, you'll see many more command-line options than those described here. As we said, virtually everything about X is configurable. fvwm (Version 2) uses a configuration file of its own, .fvwm2rc, described in its manual page. (If you have no .fvwm2rc file, the system default /usr/lib/X11/fvwm2/system.fvwmrc is used instead.) The manual pages, as well as books on using X (such as X Window System User's Guide by Valerie Quercia and Tim O'Reilly), provide more information on configuring individual clients.
Depending on which environment you use, you can't use X for long without running into X resources; they are mentioned in virtually every manual page. X resources provide a more flexible and powerful way to configure X clients than using command-line options such as -geometry and -fg. They allow you to specify defaults for entire classes of clients; for example, we could set the default font for all invocations of xterm to 7x13bold, instead of specifying it on each command line.
Recently, X resources have fallen out of favor with X developers. While they are really very flexible, they are not particularly easy to work with and feel more like a relic of ancient times. A growing number of programs are therefore customized not by X resources but instead via comfortable configuration dialog boxes. However, it still pays to know about X resources because you will come across them for a long time to come.
Using X resources requires two steps. First, you must create a file containing your X resource defaults. Typically, this file is called .Xdefaults and lives in your home directory. Second, you need to use xrdb to load the X resources into the server, which makes them available for use. In general, you run xrdb from your .xinitrc before starting any clients.
As a simple example, let's take the various command-line options used by the clients in the earlier sample .xinitrc and specify them as X resources instead. Afterwards, we'll show you what kinds of changes need to be made to .xinitrc to make use of the resources.
First a few words about resources and how they work. Each X application is part of a certain application class. For example, xterm is a member of the XTerm class. xclock and oclock are both members of the Clock class. Setting resources for the Clock class affects all applications that are part of that class; because xclock (a square analog clock) and oclock (an oval analog clock) are similar, they belong to the same class and share the same resources. Most applications are members of their own exclusive class; xload is the only member of the XLoad class. However, if another xload-like application were to be written, it might be part of the XLoad class as well. Placing X clients into application classes allows you to set resources for all applications in that class. (The manual page for each X client specifies the application class the client belongs to.)
Standard X clients employ resources such as foreground, background, geometry, and font. Also, many X clients have specific resources of their own; for example, xterm defines the resource logFile, which allows you to specify a file in which to log the terminal session. Again, the manual pages for X clients specify which resources are available.
Moreover, resources themselves are arranged into a hierarchy of classes. For instance, the background resource is a member of the Background class. Resource classes allow many separate resources to be members of the same class, for which you can set resource values for the class as a whole. For example, the background resource usually determines the primary background color of a window. However, if an application window has several panels or regions, you may wish to set the background for each panel separately. There might be resources such as background1, background2, and so on, for each panel, but they would all be members of the Background resource class. Setting the resource value for the Background class sets the value for all resources in that class.
In general, you won't need to concern yourself with the differences between resource classes and the resources within that class. In most cases, it's easier to set resource values for an entire class (such as Background) instead of individual resources in that class.
Now, let's look at how resource values are set in the X resource database. A complete resource specification is of the form:[45]
The vertical bar means "choose one or the other." Let's say you want to set the background color of an xterm window. The complete resource specification might be:(ApplicationClass|applicationName)*(ResourceClass|resourceName) : value
However, this sets only a particular background resource (not all of the resources that might be in the Background class) and only for the xterm client when it is invoked as xterm (more on this later). Therefore, we might want to use resource classes instead:xterm*background: darkslategray
This resource specification will apply to all xterm clients, and all Background-class resources used by xterm.XTerm*Background: darkslategray
[45]Actually, resource specifications have a more complex syntax than this, and the rules used to determine resource and value bindings are somewhat involved. For simplification, we are presenting a reasonable model for application resource settings--and we direct curious readers to a good book on using X like the X Window System User's Guide.
Now, let's look at translating the options given in the earlier .xinitrc file into application resources. Create a file in your home directory, called .Xdefaults. For the previous sample .xinitrc, it should contain:
Lines 1-3 set the Geometry resource class for the Clock, XLoad, and XBiff application classes. On lines 6-7, we set the Foreground and Background resource classes for the XTerm class as whole. All xterm clients will use these values for Foreground and Background by default.1 Clock*Geometry: 70x70+5+5 2 XLoad*Geometry: 85x50+85+5 3 XBiff*Geometry: +200+5 4 5 ! Defaults for all xterm clients 6 XTerm*Foreground: white 7 XTerm*Background: black 8 9 ! Specific xterms 10 xterm-1*Geometry: 80x40+10+110 11 12 xterm-2*Geometry: -20+10 13 xterm-2*Font: 7x13bold 14 xterm-2*Background: darkslategray 15 16 xterm-3*Geometry: 80x25-20-30 17 xterm-3*Font: 7x13bold
On lines 10-17, we set resources specific to each invocation of xterm. This is necessary because not all of the xterms are alike; they each have different geometry specifications, for example. In this case, we have named the individual xterm invocations xterm-1, xterm-2, and xterm-3. As you can see, we set the Geometry resource for each on lines 10, 12, and 16. Also, we set the Font class for xterm-2 and xterm-3. And we set the Background class to darkslategray for xterm-2.
X resource binding rules work so that certain bindings have precedence over others. In this case, setting a resource for a specific invocation of xterm (as in xterm-2*Background on line 14) has precedence over the resource setting for the XTerm class as a whole (XTerm*Background on line 7). In general, bindings for an application or resource class have lower precedence than bindings for particular instances of that class. In this way, you can set defaults for the class as a whole but override those defaults for particular instances of the class.
Now, let's look at the changes required to .xinitrc to use the X resources defined here. First, we need to add an xrdb command, which loads the application resources into the server. And, we can get rid of the various command-line options that the resources have replaced. To wit:
As you see, the -name argument given to the three instances of xterm lets us specify the application name that xterm uses for locating X resources. Most X clients don't support a -name argument; the name used is usually the one which it was invoked with. However, because many users run several xterms at once, it is helpful to distinguish between them when setting resources.#!/bin/sh # Sample .xinitrc shell script # Load resources xrdb -load $HOME/.Xdefaults # Start xterms xterm -name "xterm-1" & xterm -name "xterm-2" & xterm -name "xterm-3" & # Other useful X clients oclock & xload & xbiff & xsetroot -solid darkslateblue & # Start the window manager exec fvwm2
Now, you should be able to modify your X environment to some degree. Of course, knowing how to configure X depends partly on being familiar with the many X clients out there, as well as the window manager (and how to configure it). The rest of this section will present various X applications for Linux. We'll also look at a particular window manager, fvwm, in detail.
|  | |
| 10.7. Running Into Trouble |  | 11.2. The fvwm Window Manager |
Copyright © 2001 O'Reilly & Associates. All rights reserved.