option - Using the option database in Perl/Tk
The option database (also known as the resource database or the application defaults database) is a set of rules for applying default options to widgets. Users and system administrators can set up these rules to customize the appearance of applications without changing any application code; for example, a user might set up personal foreground and background colors, or a site might use fonts associated with visual or language preferences. Different window managers (and implementations of them) have implemented the database differently, but most Xt-based window managers use the .Xdefaults file or the xrdb utility to manage user preferences; some use both, and/or implement a more complex set of site, user and application databases. Check your site documentation for these topics or your window manager's RESOURCE_MANAGER property.
For most applications, the option database ``just works.'' The option... methods are for applications that need to do something unusual, such as add new rules or test an option's default. Even in such cases, the application should provide for user preferences. Do not hardcode widget options without a very good reason. All users have their own tastes and they are all different. They choose a special font in a special size and have often spend a lot of time working out a color scheme that they will love until death. When you respect their choices they will enjoy working with your applications much more. Don't destroy the common look and feel of a personal desktop.
All widgets in an application are identified hierarchically by pathname, starting from the MainWindow and passing through each widget used to create the endpoint. The path elements are widget names, much like the elements of a file path from the root directory to a file. The rules in the option database are patterns that are matched against a widget's pathname to determine which defaults apply. When a widget is created, the Name option can be used to assign the widget's name and thus create a distinctive path for widgets in an application. If the Name option isn't given, Perl/Tk assigns a default name based on the type of widget; a MainWindow's default name is the appname. These defaults are fine for most widgets, so don't feel you need to find a meaningful name for every widget you create. A widget must have a distinctive name to allow users to tailor its options independently of other widgets in an application. For instance, to create a Text widget that will have special options assigned to it, give it a name such as:
$text = $mw->Text(Name => 'importantText');
You can then tailor the widget's attributes with a rule in the option database such as:
The class attribute identifies groups of widgets, usually within an application but also to group similar widgets among different applications. One typically assigns a class to a TopLevel or Frame so that the class will apply to all of that widget's children. To extend the example, we could be more specific about the importantText widget by giving its frame a class:
$frame = $mw->Frame(-class => 'Urgent'); $text = $frame->Text(Name => 'importantText');
Then the resource pattern can be specified as so:
Similarly, the pattern
The priority scheme used by core Tk is not the same as used by normal Xlib routines. In particular is assumes that the order of the entries is defined, but user commands like xrdb -merge can change the order.
database, option, priority, retrieve