Syntax for resource specifications
A resource specification consists of the following components,
For information on choosing the actual names for the
client, restrictions, and
resource_name components, see
``Using classes and instances in resource specifications''.
client is the client or application to which
you want this specification to apply. You can supply
either the client's binary or class name.
This component is
optional; if you omit this part of the specification, the
resource definition applies to all clients that support
restrictions, usually in the form of widget names
define the extent to which you want the resource definition
to effect a client's appearance or behavior.
You can only supply restrictions that are used
and understood by the client(s) you are customizing,
otherwise the resource specification is ignored.
You can specify
any number of restriction components, leaving the
resource specification very general, or narrowing its
focus to a discrete part of a client's functionality. This component
is optional; if you omit this part of the specification,
the resource definition applies to all relevant widgets of
the specified client.
resource_name is the actual resource variable that you want
to define. Each client and each widget
has a set of resources that it
recognizes. (Refer to the client's manual page for a list
of the resources that can be used to customize the application's
behavior and appearance.) This component must be specified.
resource_value is the value
that you want to assign to the resource variable.
For example, if you want to define a font
resource, you would supply a font name as the value.
Different resources require different types of input;
an overview of the various resource values you can expect to
use is provided in
``Specifying values in resource specifications''.
Refer to the manual pages of the clients you want
to configure for the values that are expected by
the clients' supported resources.
The various components of a resource specification are
separated by a delimiter, in this case the asterisk ``*'' character.
If you are unsure about what type of delimiter
to use in a resource specification,
you can always safely use the asterisk.
The delimiters, also known as ``bindings'',
are described later in
``Using delimiters in resource specifications''.
A colon and whitespace separate the client,
restrictions, and resource_name
components from the resource_value.
Be careful that you do not omit the colon at the end of
a resource specification.
This is an easy mistake to make
and the resource manager does not provide any error messages.
If there is an error in a resource specification,
including a syntax error such as the omission of the colon,
or a misspelling, the specification is ignored and the value
you set does not take effect.
The following examples show various combinations of the above
components and describe the effects the resource specifications
have on the system:
specifies that the foreground color is yellow.
Because no client is specified, the color applies to all clients.
Because no restrictions are indicated,
the color applies everywhere within all clients.
specifies that the foreground color for
the xclock client is pink.
The specification applies to all aspects of
the xclock client that use the foreground resource.
specifies that the foreground color is
blue for the topBox widget,
which is xman's main options menu.
The topBox component of the resource
specification is a restriction,
limiting the use of the foreground
resource to a small portion of the xman client.
Using classes and instances in resource specifications
© 2003 Caldera International, Inc. All rights reserved.
SCO OpenServer Release 5.0.7 -- 11 February 2003