An Introduction to Resources

When a Tk widget is created, its attributes are set by one of three sources. It is important to note that Tcl command specifications have priority over resource database specifications:

• The most evident source of attributes are the options in Tcl commands, such as the -text quit attribute specification for a button.

• If an attribute is not specified on the command line, then the resource database is queried as described later.

• If there is nothing in the resource database, then a hard-coded value from the widget implementation is used.

The resource database consists of a set of keys and values. Unlike many other databases, however, the keys are patterns that are matched against the names of widgets and attributes. This makes it possible to specify attribute values for a large number of widgets with just a few database entries. In addition, the resource database can be shared by many applications, so users and administrators can define common attributes for their whole set of applications.

The resource database is maintained in main memory by the Tk toolkit. On UNIX the database is initialized from the RESOURCE_MANAGER property on the root window, or the .Xdefaults file in your home directory. On Windows and Macintosh, there are a few resources added by the tk.tcl library file. Additional files can be explicitly loaded with the option readfile command, and individual database entries are added with the option add Tcl command.

The initialization of the database is different from the Xt toolkit, which loads specifications from as many as five different files to allow per-user, per-site, per-application, per-machine, and per-user-per-application specifications. You can achieve the same effect in Tk, but you must do it yourself. Example 45-1 on page 672 gives a partial solution.

Resource Patterns

The pattern language for the keys is related to the naming convention for Tk widgets. Recall that a widget name reflects its position in the hierarchy of windows. You can think of the resource names as extending the hierarchy one more level at the bottom to account for all the attributes of each individual widget. There is also a new level of the hierarchy at the top to specify the application by name. For example, the database could contain an entry like the following in order to define a font for the quit button in a frame called .buttons:

Exmh.buttons.quit.font: fixed

The leading Exmh. matches the class name for the Tcl/Tk application. The class name of the application is set from the name of the script file, with the first character capitalized. For example, if the script is /usr/local/bin/foobar, then the class is set to Foobar. You could also specify an asterisk to match any application:

*buttons.quit.font: fixed

Resource keys can also specify classes of widgets and attributes as opposed to individual instances. The quit button, for example, is an instance of the Button class. Class names for widgets are the same as the Tcl command used to create them, except for a leading capital letter. A class-oriented specification that would set the font for all buttons in the .buttons frame would be:

Exmh.buttons.Button.font: fixed

The application class name becomes the class name for the main toplevel window. For example, if you use a script name like button.tcl, the class for . becomes Button. This causes it to inherit all the standard Button bindings and attribute values, which can cause problems in your application.

Patterns let you replace one or more components of the resource name with an asterisk (*). For example, to set the font for all the widgets packed into the .buttons frame, you can use the resource name *buttons*font, or you can specify the font for all buttons with the pattern *Button.font. In these examples, we have replaced the leading Tk. with an asterisk as well. It is the ability to collapse several layers of the hierarchical name with a single asterisk that makes it easy to specify attributes for many widgets with just a few database entries.

The tables in this book list attributes by their resource name. The resource names use a capital letter at the internal word boundaries. For example, if the command line switch is -offvalue, then the corresponding resource name is offValue. There are also class names for attributes, which are distinguished with a leading capital (e.g., OffValue).

The matching between a widget name and the patterns in the database can be ambiguous, with multiple patterns matching the same widget. The order of database entries determines which pattern is used, with later entries taking precedence. (This is different from the Xt toolkit, in which longer matching patterns have precedence, and instance specifications have priority over class specifications.) Suppose the database contained just two entries, in this order:

*Text*foreground: blue
*foreground: red

Despite the more specific *Text*foreground entry, all widgets will have a red foreground, even text widgets. For this reason you should list your most general patterns early in your resource files and give the more specific patterns later.

Tk also supports different priorities among resources, as described in the next section. The ordering precedence described here applies to all resources with the same priority.