 |
Chapter 11. Customizing Your X Environment
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.
11.1. Basics of X Customization
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.
11.1.1. xinit
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!
Figure 11-1. Screen created by sample .xinitrc fileLet'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:
xsizexysize+xoffset+yoffset
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.
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:
xterm -geometry -20+10 -fn 7x13bold -fg darkslategray -bg white &
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.
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:
exec fvwm2
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.
[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.
11.1.2. The X Resource Database
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]
(ApplicationClass|applicationName)*(ResourceClass|resourceName) : value
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:
xterm*background: darkslategray
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.
[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:
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
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.
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:
#!/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
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.
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.
|
|
|
