X resources

Note: This section describes the general mechanism used
to configure X programs. It doesn't relate specifically to
window managers, and more recent trends mean that programs
usually provide their own means of configuration, often using a
GUI. Therefore knowing the details of X resource setting is less
useful now than it used to be.

X programs can be customized by using resources. These resources
can be specified in many different places. In order of
increasing priority these include:

1. Fallback resources programming into the application.
2. Library resource files controlled with XFILESEARCHPATH variable.
3. User resource files controlled with XUSERFILESEARCHPATH, and
   XAPPLRESDIR variables.
4. X resource database, loaded with xrdb.
5. X resource default files, $HOME/.Xdefaults or
   $HOME/.Xresources.
6. Standard command line options.
7. Hardcoded resources, set within the program.

Options nearer the end of the list override ones further up
the list. For personal customization of X programs, the best
method to use is a single $HOME/.Xresources file
($HOME/.Xdefaults will probably also work, but is
now obsolete). This file gets read when you start X. If you
have a lot of resources to set for a particular program, or
you have your own version of an X program with a resource
file, it would be best to create a directory for these
files. This directory would be searched when an X program is
started. These two methods are discussed in more detail below.

The .Xresources file

The simpliest and best way to customize X programs is to
create a file called .Xresources in the top level
of your home directory.

Any line beginning with a ! is ignored, so can be
used for comments. Each resource specification appears on a
separate line and is often of the form Client*resource:
value. The client name is specified by the program, but
unless stated otherwise, this is usually the name of the
program with the first letter capitalized, e.g. netscape
becomes Netscape, unless the first letter is an
X, in which case the first two letters are
capitalized, e.g. xterm becones XTerm. The resource
name is usually a single string, such as
scrollBar. After the colon, and any whitespace,
comes the value you wish to set the resource to. This is
always a string, which gets converted into the correct
type. So an example of a complete specification is
XTerm*scrollBar: True. This would cause all xterms
to have a scrollbar.

The resource field of the specification can actually be
preceded by a path through the widget hierarchy. In the
specification XTerm.vt100.geometry: 80x25, the
geometry resource is only specified for the vt100 widget of
the xterm, which is the main text area. If
XTerm*geometry: 80x25 was used instead, all
widgets, such as the menus which popup with Control-Mouse
button combinations, would be given the same geometry as the
main text area. Notice that in the first case, the fields were
separated by ".", and not "*". This
causes the widget you are setting the resource of to be
specified exactly, whereas the "*" means "any route
through the widget hierarchy." Any combination for
"." and "*" can be used in a resource
specification.

The order of resource specifications in a file does not
matter, as long as they do not conflict. If they do, a warning
is usually given, and the one that appears last in the file is
used. However the same resource can be specified twice if the
generality of the specifications is different. For example
Maker*background: gray70 would change the
background colour of all widgets (unless overridden later) to
be gray70. However, Maker*vertSB.background: gray65
could be used to change the background colour of all vertical
scrollbars. Thus, the more specific resource is overriding the
more general one.

Another way of specifying widgets is to name a particular
class. For example, Editres*Command.background:
yellow would set all widgets of class
commandWidgetClass, that is normal buttons, to have a yellow
background.

Examine this example .Xresources
file. It demonstates valid resource specifications in more
detail, and may contain some useful options for various
programs.

Your .Xresources file may be processed when your start your X
session. If not, add xrdb -merge ~/.Xresources to an
X login script such as ~/.xinitrc. If you edit the
resource file and you want the changes to take effect during
the current X session, you can parse it by executing:
xrdb -merge ~/.Xdefaults.

User resource files

You can also have a directory of resource files, with one file per program.
To do this,
create the directory, say $HOME/appres, and then set the environment
variable XAPPLRESDIR to point to it. So you would have something
like setenv XAPPLRESDIR $HOME/appres/ in your .cshrc file,if your shell is csh or tcsh.

Now, when you start an X program, this directory will be searched for a file
with the same name as the resource name of the program. This is the client name
used in .Xdefaults files. This file can contain identical specifications,
but the client name is optional. For example, a file called XTerm
could contain the line *background: deepskyblue.

Standard Options

Applications should document any specific resources that can be used with the
program, but there are many standard options which can be used with virtually
all X programs. These include:

• display - the X server to use
• geometry - the size and location
• background, or bg - background colour
• bordercolor, or bd - colour to use for borders
• foreground, or fg - foreground colour
• font, or fn - the font to use for displaying text
• iconic - the program should be initially iconified
• name - the name under which resources should be found
• title - the title for the program window
• xrm - specifies a resource name and value

For more details, see the man page for X.

X resources

From Wikipedia, the free encyclopedia

In the X Window System, the X resources comprise parameters of computer programs such as the name of the font used in the buttons, the background color of menus, etc. They are used in conjunction or in alternative to command line parameters and configuration files.

[edit] Format

At the X protocol level, resources are strings that are stored in
the server and have no special meaning. The syntax and meaning of these
strings is given by client libraries and applications.

Every X resource specifies a parameter for a program or one of its
components. A fully specified resource has the following format:

This resource specifies the value of attribute for the component named component.subcomponent.subcomponent of the program application. Resources are often used for specifying the parameters of widgets created by the application. Since these widgets are arranged in a tree,
the sequence of component/subcomponent names is used to identify a
widget by giving its path within the tree. The value of the resource is
the value of an attribute for this widget, such as its background
color, etc.

X resources are also used to specify parameters for the program that
are not directly related to its widgets, using the same syntax.

X resources are designed to allow the same parameter to be specified
for more than one program or component. This is realized by allowing wildcard characters in a resource specification. In particular, the ? character is used to match the application name or a single component. The *
character is used to match any number of components. These two
characters can be used anywhere but at the end of the resource name. In
other words, an attribute cannot be replaced by a wildcard character.

While the resources can be loosely specified via the wildcard
characters, queries for the value of a resource must specify that
resource exactly. For example, a resource can specify that the
background of every component of the xmail program must be red:

However, when a program (e.g., the xmail program itself, when it wants to find out which background color to use) accesses the resource database via Xlib functions, it can only request the value of a specific resource. Contrary to most databases,
the stored data can be specified loosely (via wildcard characters), but
the interrogation cannot. For example, a program can query for the
value of xmail.main.background or of xmail.toc.buttons.background, but cannot use ? or * to check the background color of several components at once.

Resources can also be specified for classes of elements: for example, application.widget.widget.attribute: value can be generalized by replacing the application name with its class (e.g., Mail instead of xmh), each widget with its type (Pane, Button, etc.), and the attribute with its type.

[edit] Location and use

During X server
execution, the X resources are stored in two standard locations,
depending on whether they apply to all screens or to a particular one:

1. the RESOURCE_MANAGER property of the root window of screen 0
2. the SCREEN_RESOURCES property of the root window of an arbitrary screen

X resources are accessible to all programs connected to the X server, even if running on different computers.

X resources are stored in the server rather than in a configuration
file to allow programs started from other computers to use them.
Indeed, a program connecting to an X server from another computer can
access the resources via the X protocol. Using the old system of storing program parameters in the .Xdefaults file creates the need of copying this file to all other computers where a program can be started.

Resources are manipulated by the xrdb program. In particular, many X server configurations run xrdb at start up, instructing it to read the resources from the .Xresources file in the user's home directory.
From this point on, every other program finds the resources in the two
standard locations. You can view the current resources from a console
with xrdb -query.

[edit] Client libraries

Xlib contains a number of convenience functions
for accessing the resources on the server and manipulating them
locally. These functions are used both by xrdb and by every other
program that needs these resources. Most of these functions manipulate
a resource database, which is a local data structure representing a set of resource specifications. The Xlib functions for resource management are:

• functions for reading the resources on the server into a local string (XResourceManagerString and XScreenResourceString)
• functions for creating, manipulating, and destroying a local resource database (XrmInitialize, XrmDestroyDatabase, XrmGetFileDatabase, XrmPutFileDatabase, XrmGetStringDatabase, XrmLocaleOfDatabase, XrmSetDatabase, XrmGetDatabase, XrmCombineFileDatabase, XrmCombineDatabase, XrmMergeDatabases, XrmParseCommand)
• functions for looking up resources and storing new ones (XrmGetResource, XrmQGetResource, XrmQGetSearchList, XrmQGetSearchResource, XrmPutResource, XrmQPutResource, XrmPutStringResource, XrmQPutStringResource, XrmPutLineResource, XrmEnumerateDatabase)

In particular, the function XrmParseCommand allow parsing the command line
arguments, reading resources that are then added to a local resource
database. This way, the resources can be read from the server and used
as defaults that are overridden by command line arguments.

For the sake of efficiency, integers called quarks are defined to represent local strings. Quarks are similar to atoms,
but they represent strings stored locally rather than on the server. A
number of Xlib functions create an association between strings and
quarks. Quarks can be used in place of component names when using one
of the above functions; resource names therefore correspond to quark
lists.