Tkinter 8.5 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
.Xdefaultsfile 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 26, “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 26, “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 theFrameclass, and give them new names of your own creation. See Section 27.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 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.