|
Resources
If we wanted, we also could have included the geometry along with the colors, which would give us
a command that is almost too long for the screen. Even now it is a long command that takes a long
time to type in, and you can easily make mistakes. One solution would be to write everything in a
shell script and start that script instead of typing everything on the command line.
The nice thing is we don't have to do this. X
provides a mechanism to change the appearance and sometimes the behavior of a client
to fit our personal preferences. This is the concept of a resource. Up to now, we have specified the resource from the command line, such as foreground color and geometry.
However, there are resource files that we can edit to change the default characteristics of a given client.
Resource files for most applications are found in /usr/lib/X11/app-defaults. The general form of
the resource specification is
appname*subname*subsubname...:value
The application
is the name of the program you are starting,usually with the first letter capitalized. Note the word "usually." I don't know how many times I've tried to change a resource and not have it work, only to find out that this one applications name is written in lowercase. In the case of the files in /usr/lib/X11/app-defaults, no appname is necessary because there is one file for each client and X knows what client is meant when it reads these files. If set, X will search the path specified by the XFILESEARCHPATH variable for the resource information.
Unless you want to change the system defaults, I suggest that you leave these files alone.
Instead, you can create a user- or machine-specific resource file. Normally, this
is $HOME/.Xdefaults--hostname, where hostname is the name of the host to which these resource specifications apply. If the .Xdefaults file is to apply to the local host, you can omit the hostname. If you want to specify an alternative file, you can use the ENVIRONMENT variable.
These resources are organized into classes, which enables you to set groups of individual
resources all at once. Individual resources are referred to as an instance. By convention,the
class name begins with an uppercase letter and the instance begins with a
lowercase letter. We can generally say that a resource (both class and instance)is named for the
aspect of appearance that it controls. For example, the class called Foreground sets the foreground color. An instance of the Foreground class would be specified with a lowercase "F": foreground. Keep in mind that different parts of the clients are affected by the class Foreground, such as the text color, cursor color, and pointer color.
Basically all applications have resources. In each case, the class
name has an initial capital. Examples of this are
background | window background color |
border Width | width in pixels of the window border |
border Color | windowborder color |
foreground | window foreground color |
The distinction between classes and instances is very useful if you want to set several resources
at once. For example, if you define the foreground color for all aspects of the XTerm, the resource
definition would look like this:
XTerm*Foreground: blue
This would be equivalent to
XTerm*foreground: blue
XTerm*cursorColor: blue
XTerm*pointerColor: blue
This means that the foreground color of text,
cursor,
and pointer are all blue. If we then defined the pointerColor instance to be something else, only
it changes. For example, if we made the following definition
XTerm*pointerColor: red
the color is now red, although all the others remain blue.
Although the asterisk is perhaps the most commonly used delimiter, it's not the only one. The
asterisk delimiter is used to indicate a loose binding, in which there can be
several layers in the object hierarchy. It's easy to think of the asterisk as having the same
function as on the command line, that is, as a wild card. Here, the asterisk
represents 0 or more intermediate layers between the root object and the resource we are defining.
If there are no intermediate layers between the objects, this referred to as a tight
binding. If you wanted this, you could specify the binding with the asterisk because it means 0 or more intermediate levels. However, the symbol used to explicitly specify a tight binding is a dot (.). Because I know that the level just before the pointerColor in the hierarchy is "ansi," I can make the specification like this:
XTerm*.ansi.pointerColor: red
However, because the loose binding specifier (*) can be used any place though the tight binding specifier (.) can be used only when appropriate, it is easier always to use the loose binding specifier.
Both the resource specifications and binding
can bring up some conflicts. In the example above, we said to use blue for every foreground color related to the client "XTerm." We also said to use red for the foreground color of pointer. Now this seems like a conflict, which it is. However, in this case, the instance of the pointerColor took precedence over the class of Foreground.
Consider these lines from an .Xdefaults file:
XTerm*Foreground: blue
XTerm*pointerColor: red
XTerm*ansi.pointerColor: green
We first defined the Foreground class
to be blue. Next, we defined the instance of the pointerColor to be red. Both of these are done with loose bindings. We then defined the instance of the pointerColor for an ANSI
terminal to be green. Because tight bindings have precedence over loose
bindings, the pointer is green.
Taking this one step further, we change the class
specification so it contains a tight binding.
However, we leave the instance specification a loose binding. So, we end up with these two lines:
XTerm*ansi.Foreground: blue
XTerm*pointerColor: red
In this case, there is a tightly bound class
specification that is followed by a loosely bound instance specification. When we start the XTerm, the pointer is blue, not red. In general, we can say that the more specific a specification is, the greater the precedence.
There are a limited number of options that we can use from the command line,
although there are many more resources that we might want to change. To accommodate a large number of resource without increasing the number of options, we use the -xrm option. For example, if we wanted to change the tty modes of XTerm (what the characters are for erase, delete, quit, etc.), we could do this using the -xrm option and specifying an instance of the TtyModes class. For example, to change the interrupt key from the
default of Del to Ctrl+C, the command would look like this:
XTerm -xrm XTerm*ttyModes: intr ^C &
Keep in mind that this resource specification is only valid for this one XTerm that we are
starting here. If we wanted it to be valid for all XTerms, we would either change the default in
/usr/lib/X11/app-defaults or define the resource in the .Xdefaults file.
| 
Back to Top
