Next / Previous / Contents

27. Standardizing appearance and the option database

It's easy to apply colors, fonts, and other options to the widgets when you create them. However,

  • if you want a lot of widgets to have the same background color or font, it's tedious to specify each option each time, and

  • it's nice to let the user override your choices with their favorite color schemes, fonts, and other choices.

Accordingly, we use the idea of an option database to set up default option values.

Before we discuss how options are set, consider the problem of customizing the appearance of GUIs in general. We could give every widget in the application a name, and then ask the user to specify every property of every name. But this is cumbersome, and would also make the application hard to reconfigure—if the designer adds new widgets, the user would have to describe every property of every new widget.

So, the option database allows the programmer and the user to specify general patterns describing which widgets to configure.

These patterns operate on the names of the widgets, but widgets are named using two parallel naming schemes:

  1. Every widget has a class name. By default, the class name is the same as the class constructor: 'Button' for buttons, 'Frame' for a frame, and so on. However, you can create new classes of widgets, usually inheriting from the Frame class, and give them new names of your own creation. See Section 27.1, “How to name a widget class” for details.

  2. You can also give any widget an instance name. The default name of a widget is usually a meaningless number (see Section 5.11, “Window names”). However, as with widget classes, you can assign a name to any widget. See the section Section 27.2, “How to name a widget instance” for details.

Every widget in every application therefore has two hierarchies of names—the class name hierarchy and the instance name hierarchy. For example, a button embedded in a text widget which is itself embedded in a frame would have the class hierarchy Frame.Text.Button. It might also have an instance hierarchy something like .mainFrame.messageText.panicButton if you so named all the instances. The initial dot stands for the root window; see Section 5.11, “Window names” for more information on window path names.

The option database mechanism can make use of either class names or instance names in defining options, so you can make options apply to whole classes (e.g., all buttons have a blue background) or to specific instances (e.g., the Panic Button has red letters on it). After we look at how to name classes and instances, in Section 27.3, “Resource specification lines”, we'll discuss how the options database really works.