[Tkinter Series 13/15] Standardized appearance and options database

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:

  1. 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

  2. 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 . JukeboxFrame

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.ListboxfontfontListbox

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: JukeboxJukebox

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: *Jukeboxbackground backgroundJukebox

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. JukeboxJukebox

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. backgroundListbox

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:

  1. The name of the option must match the o part of . For example, if the rule is option-pattern

    xparrot*indicatoron: 0

    This will only match options named . indicatoron

  2. 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

  3. 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

  4. Rules with more levels are more specific. For example, the rules for IS are more specific than the rules for . *Button*font*font

  5. 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