Many aspects of an application's appearance and behavior, such as location on the screen, color, and size, are controlled by sets of variables called resources. Resources are assigned values that determine specific characteristics of an application. Depending on a resource's function, it can take values that are either names, numbers, or Boolean values. For example, if the resource sets the color of an application or part of an application, you specify a predefined color string value as the resource's value, such as DarkSlateBlue or Black. If the resource sets the title line of an application, you can specify a name string of choice. You can also set the resource to a numeric value for operations like defining the location of the application. Some resource values are set with values of either True or False.
Application resources take values that can be set a number of different ways. Resources whose values are not set are assigned default values. Each application builds an initial database of resources based on the supplied and default values.
The setting of an application's resource database is a linear process. Different values for the same application resource(s) can be set at different times before an application is actually started up. The resource database is updated as resource values are changed.
The value that is finally set for a resource depends on when during the hierarchical process that particular value was being set. However, the setting of an application's resources are not dynamic. Resource values that are set after an application has already been started do not take effect until that application is restarted.
The application resource database is set up according to the following hierarchy, from the highest to lowest precedence:
For example, if the color of an application was set to Blue in an application-specific user resource file on the local host, but you specified, during the command-line invocation, that this application's color be set to Red, then the same resource was defined for two values, with the command-line resource setting of Red overriding the earlier setting of Blue. Thus, Red is registered in that application's resource database. Note that most applications have default values to which resources are set if you do not specify a value for a particular resource.
As you can see from the listed hierarchy, applications often set up their database of resource values using existing resource files. Some of these resource files come with the system, and some are files that you create yourself.
The following subsections describe in more detail the different ways that an application's resource database can be set.
Most applications provide command-line options that allow
users to set resource values. These options, listed in Table 4-1, provide
customization for the most common resources.
Table 8. Some Standard X Command-Line Options
Option
|
Abbreviation
|
Description
|
|---|---|---|
--background
|
--bg
|
Color of the window's background
|
--bordercolor
|
--bd
|
Color of the window's border
|
--borderwidth
|
--bw
|
Width of the border in pixels
|
--display
|
--d
|
Display on which the client can run
|
--foreground
|
--fg
|
Color of the text or drawings
|
--geometry
|
--g
|
Size and placement
|
--iconic
|
--i
|
Start application as an icon
|
--name
|
--n
|
Name of the application
|
--reverse
|
--rv, +rv
|
Reverse foreground and background colors
|
--title
|
--t
|
Text displayed in the title bar
|
--xrm
|
None
|
Next argument contains any resource specification
|
In most cases, these options will correspond to specific resources. For example, if you use the --background option to change an application's background color, the background resource value is set to that color. Note, however, that option names are not always the same as the resource they are setting values for.
Setting resource values at the command line is useful to set up an application in a particular way just this once. However, if you intend to use the same resource setting for that particular application, you should put the resource specification into your user-preferred resource file (typically .Xdefaults in your home directory).
Next in the hierarchical priority is the setting of user- and machine-specific resources. At initialization, the application checks if the XENVIRONMENT environment variable has been set to the name of a specific resource file. If one has been set, then the application gets resource value settings from this file. If the environment variable has not been set, then the application initialization operation looks in the file $HOME/.Xdefaults- host, where host is the name of the host or machine running the application. This is a resource file that you can set up to run on your particular machine.
As of Release 5 of the X Window System (X11R5), any per-screen properties can be set and stored in the SCREEN_RESOURCES property of the root window of the default screen of the application's display. For example, you can specify color resources for a color screen and monochrome resources for a monochrome screen. A resource database is created for each screen, and the application finds the resources that are appropriate for each screen. The database is used to define resources when multiple screens are in use and, if some resources are not defined for all screens, it is typically set up with the
xrdb -screenor
xrdb -screenscommand. The former sets the SCREEN_RESOURCES property for the display's default screen, the latter for a display's multiple screens. Note, however, that when the system needs resources for a screen that is not the display default, it uses the SCREEN_RESOURCES property of that other screen instead of the display's default.
General resources that apply to all the screens of a display can have these common resources set and stored in the RESOURCE_MANAGER property of the root window on the default screen of the display. You can also use this property to set the resources of a screen if it is the only screen of a display. This property is typically set up with the
xrdb -globalcommand if some resources are not defined for all screens. If this property does not exist, the contents of the file .Xdefaults in your home directory are used instead. Your personal .Xdefaults file is the resource file where you usually put resource specifications that customize applications for your own use.
You can also have your own application-specific resource file to set resources. This file sets resources for just one particular application, typically for one user or group of users. Usually, the name of the application-specific resource file is listed in that application's associated reference page, and is the name of that application's class. As an example of an application-specific resource file name, the application-specific resource file for the xcal application is named XCal.
When an application looks for an application-specific resource file, it first checks the XUSERFILESEARCHPATH environment variable, which controls the search path that applications use to find application-specific resource files, then the XAPPLRESDIR variable, then an implementation-dependent predefined search path starting from the user's home directory. Refer to Section 4.1.1.7 for a description of file search paths.
To set all the resources of a particular application class, an application-specific class resource file should be used. Application class resource files are application-specific default files that are defined for the entire system. However, instead of being named with the application name, they are named the according to the application's class name. For example, the xcal application has a class name of XCal, which would also be the name of its application-specific default file. Application default files are typically predefined and not generally accessible to the user. But, you can check these files to see what the default values are for particular applications, then change them in your own user-specific resource files or on the command line.
When an application looks for an application-specific class resource file, it first checks the XFILESEARCHPATH environment variable for guidance, then it uses an implementation-dependent predefined search path.
An application searches for resource files and any localized databases on a file search path. A file search path is an ordered set of pathnames. If a resource file is not found in the first location, the application searches in the next location, and so on, until a resource file is found or all of the locations have been searched.
File search paths can incorporate a set of substitution characters that represent variable data. At run time, an application looks at certain external data and supplies corresponding values for each substitution character in the file search path. X applications accept the following substitution characters:
For example, %N can represent the class name of an application. When %N is in a path description, the application class name is substituted into the pathname. If the first path in a search path hierarchy is /usr/lib/X11/app-defaults/%N and the application class name is Mailer, the %N substitution causes the application to look in the directory /usr/lib/X11/app-defaults for a file named Mailer, which contains its application class defaults.
There are a number of environment variables that you can set to specify the search paths that an application uses to find various resource files. For example, the XUSERFILESEARCHPATH environment variable controls the search path that applications use to find your application-specific resource files. You can also set the XENVIRONMENT, XFILESEARCHPATH, and XAPPLRESDIR environment variables to specify search paths for other aspects of resource lookup.
For more information about these features, refer to the Programmer's Supplement for Release 5, 1991, published by O'Reilly and Associates, Inc.