27. Standardized appearance and options database
Colors, fonts, and other options can be easily applied to widgets as you create them. However
-
If you want many widgets to have the same background color or font, it would be tedious to specify each option every time, as well
-
It’s good to let users override your choices with their favorite color schemes, fonts, and other choices.
Therefore, we have the idea of using options database to set default option values.
-
Applications can specify files (such as the standard files used by the X Window System) that contain the user’s preferences. You can set up your application to read this file and tell Tkinter to use these default values. See the section above about the .option_readfile() method in Section 26, “Generic Widget Methods” for the structure of this file.
.Xdefaults
-
Your application can specify a default value directly for one or multiple types of widgets using the .option_add() method; see this method under Section 26, “Generic Widget Methods”.
Before we discuss how to set options, consider the question of customizing the appearance of the GUI in general. We could name each widget in the application and then ask the user to specify each property for each name. But this is cumbersome, and also makes the application difficult to reconfigure – if the designer adds a new widget, the user must describe every property of each new control.
Therefore, the options database allows programmers and users to specify a general pattern that describes the widgets to be configured.
These modes operate on the name of the widget, but widgets use two parallel naming schemes:
-
Each widget has a class name. By default, the class name is the same as the class constructor: used for buttons, frames, etc. However, you can create new widget classes, usually inheriting from the class, and give them new names of your own creation. See Section 27.1, “How to Name Widget Classes” for details.
'Button'
'Frame'
Frame
-
You can also provide an instance name for any widget. The default name for a widget is usually a meaningless number (see Section 5.11, “Window Names”). However, like widget classes, you can specify a name for any widget. See Section 27.2, “How to Name Widget Instances” for details.
Therefore, every widget in every application has two hierarchies of names – a class name hierarchy and an instance name hierarchy. For example, a button embedded in a text widget, which itself is embedded in a frame, will have a class hierarchy. It might also have an instance hierarchy kind of like if you named all instances that. The initial point represents the root window; for more information, see Section 5.11, “Window Names” for information on window pathnames. Frame.Text.Button
.mainFrame.messageText.panicButton
The options database mechanism can use the name or instance name of either class when defining the option, so that you can make the option apply to the entire class (e.g., all buttons have a blue background) or to a specific instance (e.g., the panic button has red letters) . After we’ve looked at how to name classes and instances, in Section 27.3, “Resource Specification Lines”, we’ll discuss how the options database does work.
27.1. How to name widget classes
For example, assume this is a new widget class that has been created. It’s probably best to have the new widget class inherit from the class, so to Tkinter it’s like a frame where you can arrange other widgets such as labels, items and buttons within it . Jukebox
Frame
You can set the class name of a new widget by passing the name as a parent option to the constructor in the new class’s constructor. Here is a code snippet that defines a new class: class_
class Jukebox(tk.Frame): def __init__(self, master): '''Constructor for the Jukebox class ''' tk.Frame.__init__(self, master, class_='Jukebox') self.__createWidgets()
27.2. How to name widget instances
To provide an instance name for a specific widget application, set the widget’s options to a string containing the name. name
Below is an example of an instance name. Suppose you are creating multiple buttons in your application, and you want the instance name to be . The call to the constructor might look like this: panicButton
self.panic = tk.Button(self, name='panicButton', text='Panic', ...)
27.3. Resource Specification Line
Each line in the options file specifies one or more options in one or more applications, and has these formats:
app option-pattern: value option-pattern: value
Matches only if the name is Application; the second form sets the options for all applications. app
For example, if your application is called xparrot, the rows of the form
xparrot*background: LimeGreen
Set all options in the Xparrot application to Lime Green. (Use options on the command line when launching the application to set name to .) background
-name
'xparrot'
This section has the following syntax: option-pattern
{<!-- -->{*|.}name}...option
That is, each is a list of zero or more names, each preceded by an asterisk or period. The last name in the series is the name of the option you are setting. The names for everyone else could be: option-pattern
-
The name of the widget class (uppercase), or
-
The name of the instance (lowercase).
The way options patterns work is a bit complicated. Let’s start with a simple example:
*font: times 24
This line says that all options should default to 24 pips. This is called a loosely bound notation and means that this option pattern applies to any option anywhere in any application. Compare this example: font
*
font
*Listbox.font: lucidatypewriter 14
The period between and is called a tight binding symbol, which means that this rule only applies to widget options in the class.Listbox
font
font
Listbox
As another example, suppose your xparrot application has an instance of the widget class. In order to set the default background color for all widgets of this class, you can put a line in the options file like this: Jukebox
Jukebox
xparrot*Jukebox*background: PapayaWhip
A loose binding between the and() symbols makes the rule apply to any of the following options. Compare this option line: *
Jukebox
background
background
Jukebox
xparrot*Jukebox.background: NavajoWhite
This rule will apply to the frame that makes up the widget itself, but due to tight binding symbols it will not apply to widgets located within a widget. Jukebox
Jukebox
In the next section, we’ll discuss how Tkinter calculates the exact option values to use if there are multiple resource specification lines that apply.
27.4. Resource matching rules
When creating a widget, some options are not specified and the values of two or more resource specifications apply to that option, the most specific one applies.
For example, assume your options file contains these two lines:
*background: LimeGreen *Listbox*background: FloralWhite
Both specifications apply to options in widgets, but the second one is more specific, so it wins. background
Listbox
Typically, the names in resource specifications are the sequences N 1
, N 2
, N3
, …, o
where each ni
is a class or Instance name. Class names are ordered from highest to lowest level, where O
is the name of the option.
However, when Tkinter creates a widget, all it has is the widget’s class name and instance name.
The following are the precedence rule specifications for the resource:
-
The name of the option must match the
o
part of . For example, if the rule isoption-pattern
xparrot*indicatoron: 0
This will only match options named .
indicatoron
-
The tightly bound operator () is more specific than the loosely bound operator (). For example, a row is more specific than a row.
.
*
*Button.font
*Button*font
-
A reference to an instance versus a reference to a class. For example, if you have a button with an instance name of , the rules are smaller than the rules for .
panicButton
*panicButton*font
*Button*font
-
Rules with more levels are more specific. For example, the rules for IS are more specific than the rules for .
*Button*font
*font
-
If two rules have the same number of levels, the name earlier in the list is more specific than the later name. For example, rules are more specific than rules for .
xparrot*font
*Button*font
The knowledge points of the article match the official knowledge files, and you can further learn relevant knowledge. Python entry skill treeDesktop application developmentTkinter340340 people are learning the system