We will at this point consider some finer modifications to your system. Configuring the window manager only gets you so far. The window manager lets you customize everything that happens outside the windows, the frames, the borders, the buttons, the desktop... but what about making the inside of the windows pretty? The only way to do this is by modifying the X Resources for your system.
X Resources provide a mechanism for storing default values for program resources and tailoring your windowing environment to your favored look and feel. Resources are specified as text strings that are read in from various places when an application is run. Program components are named in a hierarchical fashion, with each object in the hierarchy identified by a class as well as an instance name. At the top level of the hierarchy is the class and instance name of the application itself. By convention, the class name of the application is the same as the program name, but with the first letter capitalized (e.g. Bitmap or Emacs) although some programs that begin with the letter ``X'' also capitalize the second letter for historical reasons (e.g. XTerm).
Let's try a few examples to ease you into the world of resources. Start by opening an xterm window. Most likely you have one open already, can open one with a menu selection, or may wish to backtrack a bit in this document to get your bearings! Type something like this into the xterm window:
xterm -background blue &
This command should have resulted in another xterm window popping up on your screen, but this time with a blue background. ``Wow,'' you say, ``that's amazing!'' Yes, indeed it is.
We'll need a little more background for our next example. Type exit in that xterm (which will close that window) and go back to the original window that you typed that command in. Try this: hold the Ctrl key and then hold the left mouse button. Now try that with the middle mouse button. Now the right. All xterm windows give you options to try while they are running. With the right button, for instance, you can change the font of the window. Notice the color of these menus. Now try this example:
xterm -xrm 'xterm*fontMenu*background: green' &
This time, it just looks like a normal xterm window. But if you try holding Ctrl and the right mouse button in that window, you will see that this menu (the ``fontMenu'' mentioned in the above example) is green. What just happened? If you look at the man page for xterm, you will see many command-line options, such as -background or -font, that you can set when you launch any given window in X, listed after the options just for xterm windows. These particular options are called X Toolkit Options, and they apply to just about anything in X.
To really get inside the resources of X, we need to run editres. Go ahead and launch it (and a sample program to play with) now:
xclock &
editres &
Probably you will see a simple clock, and the rather innocent looking,
mostly-blank window of editres. The main window is showing us
the resource tree of any given window on our desktop, and upon program
launch, there is none. So let's give it one. Hold down the left button
on
the Commands menu, and select Get Tree. In the top of the window will
appear Click the mouse pointer on any toolkit client. This
message is more than it seems, and it is a hint to us that not all X
applications are toolkit clients (though most of the basic ones are,
and
the program will usually tell us if it is not in the manual page). The
mouse cursor will turn to a crosshair, and wait for you to click on
another window.
For this example, let's first click on the xclock. You will see a couple things appear in the editres window. These are the configurable branches that the toolkit sees. Click on the bottom right one (clock). It should invert. Now select ``Show Resource Box'' from the ``Commands'' menu. You will see another window pop up, with the heading ".xclock.clock.unknown". Bingo!
>From here you can toy with the configuration options of the main xclock window. First, click on ``Set Save File'' at the bottom, and put in a filename such as /home/yourname/resources, to indicate that you're testing some of the resources here. Now click on ``foreground'' and put in ``blue'' next to the ``Enter Resource Value:'' prompt. Then hit ``Apply'' at the bottom. The minute notches around the clock should turn blue. Go to ``background'' and enter ``navajowhite'' (or whatever color you prefer). The apply that. As you can see, we can configure the whole window just fine this way. But if you were to try launching another xclock, it would appear just as this one appeared before any changes. We need to save these changes.
Click ``Save'' and then ``Popdown Resource Box'' (a fancy name indeed for the ``Close'' function!). If you view the file you just created (cat /home/yourname/resources perhaps) you will see all those resources spelled out, in correct X Toolkit format, for your convenience. But that does us little good, for if you try launching another xclock, it will still look Plain Jane. So here is the last and final step in loading in your resources:
xrdb -merge /home/yourname/resources
This command merges the resources we just wrote into the X
Resource Database (xrdb) for your session of X Window.
That
means that for all future invocations of the X applications we
modified,
our changes will take place, and remain binding. So if you run another
xclock, it will look as nice as you have just now set it up,
every time you run it. Mind you, xrdb is a complex program,
and
you may want to have a look at the man page before moving on, or
playing
around with it some more. If you added the modification to
.xinitrc listed earlier in this document, to load the
resources
automatically on X startup, you should only have to worry about the
xrdb command when you make changes during your X session.
As you can see we have stumbled across a plethora of configuration options here. This method of configuring X, as has been stated, offers nearly limitless possibilities, and an equivalent amount of confusion. To get some picture of the scope of the resources in just the X Toolkit Intrinsics alone, run the program viewres, and play around with it a bit. This program graphically displays the tree of resources in the Xt Library.
If you read the manual page for X, you will find a rather obscure definition of the exact syntax for defining resources it understands. We can simplify this quite a bit and break it down into this essential syntax definition:
<program><binding><widget><binding><widget><...><resource>:<value>
That doesn't really seem that simple, actually. Well, let's define some things about what has just been said, and it will all start to make sense after all. You can peek ahead to the examples in the next section as you read along, if you wish.
The program in this definition is the invocation of an
application in the resource database. This would be XTerm
for an invocation of xterm, emacs for an invocation
of the emacs text editor, or a user-defined name that was
given when the applications was launched with the -name
command line option. In this way you can define separate resources
for xterms which will be used in different ways. Which is
pretty cool, really.
The binding can be one of two characters to separate the
widgets and such. If you use a . (period), you get a
tight binding, which means that one widget is directly above
or below the other in the widget hierarchy. This also has the highest
precedence of the specification methods. If you use a *
(asterisk), you get a so-called loose binding, and you will
skip any number of widgets in the hierarchy, and it will attempt to
match the next possible widget defined.
The widget entries are items in the widget tree, in order of
most-specific to least-specific, that they appear in the widget tree,
visible with editres. Any single widget entry can also be
replaced with a ? (question mark) to skip a single widget
definition, and match any possible widget item.
The resource item must be specified, and cannot be replaced
with
the ? character. This is the most-specific item in the
hierarchy, and usually contains items like the actual color to define,
actual font to define, and so forth. In fact, everything else before
the
resource in this definition can be left out and replaced with a single
asterisk, but the actual resource to define must be present. If you
just
put an asterisk and the most-specific resource name, such as
*background: blue, X will attempt to define that resource
globally, for all its clients, if possible.
Following the colon is the value entry. This entry defines what the resource will be set to, such as a font name or color value. The value can be specified (depending on context) as a boolean, numeric, or text data type. The value entry, also, cannot be omitted in a valid resource definition.
There is a magic file you can put in your home directory called .Xdefaults. If you copy the lines in the resources file from the last example into the .Xdefaults in your home directory, you will never have to configure xclock again! While this might not be the finest example of its utility, it makes its point. This file can be crammed full of every option you prefer for every type of program you run in X, and if you take proper care of it, you can still easily go back and make slight changes when you need to. But making lots of changes, and hunting down lots of subtle resources using editres can be an extremely tiring and painstaking procedure. Indeed, sometimes that's too much work, and most of these resources are already waiting for you, neat and orderly, grouped by program, on your system.
In the directory /var/X11R6/lib/app-defaults you will find a great many files, all named after an X Toolkit program. If you examine these files you will find that they contain a great many configuration options for each one, and I do mean a great many! You would not want all of these options from all of these files in your .Xdefaults file, that would be quite tiresome to deal with. These are the defaults, and it is from these that you can decide what you would like to see changed for your particular configuration.
The following are some samples from my .Xdefaults file. Notice
a
few things we have not yet mentioned about the resource definition
files. If a line begins with ! (exclamation point), it is
considered a comment, and the rest of the line is ignored. If the line
begins with #include filename, that line is an
include directive, and at that point in the resources another
file will be merged, when it is loaded. This can help keep your
resource
files from becoming too bloated. And here are some examples:
! Default resources for me@localhost xterms
! start with the generic, move to the specific...
*Dialog*Text*font: -b&h-lucida-medium-r-*-*-12-*-*-*-*-*-*-*
*dialog*value*background: white
*Dialog*Label*font: -adobe-helvetica-bold-r-*-*-12-*-*-*-*-*-*-*
*MenuButton*font: -adobe-helvetica-medium-r-*-*-12-*-*-*-*-*-*-*
*MenuButton*background: grey80
*MenuButton*foreground: black
*Label.font: -adobe-helvetica-medium-r-*-*-10-*-*-*-*-*-*-*
*Label*shadowWidth: 1
*SmeBSB.font: -adobe-helvetica-bold-r-*-*-12-*-*-*-*-*-*-*
*SimpleMenu*font: -adobe-helvetica-medium-r-*-*-10-*-*-*-*-*-*-*
*OptionMenu*font: -adobe-helvetica-medium-r-*-*-10-*-*-*-*-*-*-*
*Command.font: -linotype-helvetica-bold-r-narrow-*-12-*-*-*-*-*-*-*
*commandBox*font: -b&h-lucida-bold-r-*-*-12-*-*-*-*-*-*-*
*Toggle.font: -adobe-helvetica-bold-o-*-*-12-*-*-*-*-*-*-*
*Form.background: grey70
*TransientShell*Dialog.background: grey70
*Scrollbar.Foreground: grey80
*Scrollbar.Background: grey50
*Scrollbar*cursorName: top_left_arrow
*Scrollbar*width: 16
*shapeStyle: Rectangle
*XlwMenu.shadowThickness: 1
*shadowWidth: 1
! xterm stuff
xterm*scrollbar.background: grey40
xterm*foreground: grey90
xterm*background: grey25
xterm*cursorColor: white
xterm*visualbell: on
! rxvt stuff (a quicker, better xterm)
rxvt*color12: steelblue
rxvt*color15: white
rxvt*color9: rgb:ff/7f/5f
rxvt*foreground: grey90
rxvt*background: grey10
rxvt*cursorColor: white
rxvt*font: lucidasanstypewriter-12
rxvt*loginShell: false
rxvt*saveLines: 1024
rxvt*title: shell
rxvt*geometry: 80x25
! Make Xman just a little bit more sane
xman*topBox: false
xman*background: lightsteelblue
xman*foreground: black
! xcalc is too bland by default...
xcalc*Command.font: -adobe-helvetica-bold-r-*-*-10-*-*-*-*-*-*-*
xcalc*customization: -color
! Disallow the <blink> tag in Netscape
Netscape*blinkingEnabled: False
! Merge other resources (example)
# include $HOME/.otherXresources
One word of warning with regard to X resources. KDE users will find that their X resources are ignored. That's right. They are. I'm not actually aware of any way to get around this at present, nor have I looked into it extensively. KDE configures your resources for you, so that all your X applications have the same look and feel, sort of. This can be very disorienting if you're switching between window managers. If anybody knows how to get around this (read: fix it ;) please let me know.
You can also create a directory of resource files, just like the
system-wide app-defaults directory mentioned above, with one
file
per program. Just create the directory (for our example we'll use
app-defaults under your home directory,) and then set the environment
variable XAPPLRESDIR to point to it. A good place to set this
variable would be in the beginning of your .xinitrc file, for
example, put in the line export XAPPLRESDIR=$HOME/app-defaults
(if
your files are going to be in an app-defaults directory under
your
home directory).
Now, whenever you start an X program, this directory will be searched
for
a file with the same name as the resource name of the program, just
like
the system-wide directory. This is the client name that you
used in .Xdefaults files.
For example, a file called XTerm could contain the line
*background: gold, and all your xterms would, by
default,
come up with a gold background. This is a nice alternative to a single
.Xdefaults file, and makes it more clear when trying to decide
which settings to configure later on, and to find the ones for a
certain
program. There are still uses for the .Xdefaults, though.
It's
useful for setting resources not bound to a single program, like
modifications that you would make to turn all of a certain kind of
button
blue, regardless of the application.