Tkinter reference: a GUI for Python |  |
Tkinter reference: a GUI for Python | |
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.
Your application can specify a file (such as the
standard .Xdefaults file used by
the X Window System) that contains the user's
preferences. You can set up your application to read
the file and tell Tkinter to use those defaults. See
the section on the .option_readfile() method, above,
in the section on Section 19, “Universal widget methods”, for the
structure of this file.
Your application can directly specify defaults for
one or many types of widgets by using the .option_add()
method; see this method under Section 19, “Universal widget methods”.
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:
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 20.1, “How to name a widget class” for
details.
You can also give any widget an instance name. The default name of a widget is usually a meaningless number (see Section 4.11, “Window names”). However, as with widget classes, you can assign a name to any widget. See the section Section 20.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 4.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 20.3, “Resource specification lines”, we'll discuss how the options database really works.