1ttk::intro(n) Tk Themed Widget ttk::intro(n)
2______________________________________________________________________________
6
8 ttk::intro - Introduction to the Tk theme engine
9______________________________________________________________________________
10
12 The Tk themed widget set is based on a revised and enhanced version of
13 TIP #48 (https://tip.tcl-lang.org/48) specified style engine. The main
14 concepts are described below. The basic idea is to separate, to the
15 extent possible, the code implementing a widget's behavior from the
16 code implementing its appearance. Widget class bindings are primarily
17 responsible for maintaining the widget state and invoking callbacks;
18 all aspects of the widget's appearance are controlled by the style of
19 the widget (i.e. the style of the elements of the widget).
20
22 A theme is a collection of elements and styles that determine the look
23 and feel of the widget set. Themes can be used to:
24 • isolate platform differences (X11 vs. classic Windows vs. XP vs.
26 Aqua ...)
27 • adapt to display limitations (low-color, grayscale, monochrome,
29 tiny screens)
30 • accessibility (high contrast, large type)
32 • application suite branding
34 • blend in with the rest of the desktop (Gnome, KDE, Java)
36 • and, of course: eye candy.
38
40 An element displays an individual part of a widget. For example, a
41 vertical scrollbar widget contains uparrow, downarrow, trough and
42 slider elements.
43 Element names use a recursive dotted notation. For example, uparrow
45 identifies a generic arrow element, and Scrollbar.uparrow and Com‐
46 bobox.uparrow identify widget-specific elements. When looking for an
47 element, the style engine looks for the specific name first, and if an
48 element of that name is not found it looks for generic elements by
49 stripping off successive leading components of the element name.
50 Like widgets, elements have options which specify what to display and
52 how to display it. For example, the text element (which displays a
53 text string) has -text, -font, -foreground, -background, -underline,
54 and -width options. The value of an element option is taken from (in
55 precedence order):
56 • an option of the same name and type in the widget containing the
58 element;
59 • a dynamic setting specified by style map and the current state;
61 • the default setting specified by style configure; or
63 • the element's built-in default value for the option.
65
67 A layout specifies which elements make up a widget and how they are ar‐
68 ranged. The layout engine uses a simplified version of the pack algo‐
69 rithm: starting with an initial cavity equal to the size of the widget,
70 elements are allocated a parcel within the cavity along the side speci‐
71 fied by the -side option, and placed within the parcel according to the
72 -sticky option. For example, the layout for a horizontal scrollbar is:
73 ttk::style layout Horizontal.TScrollbar {
75 Scrollbar.trough -children {
76 Scrollbar.leftarrow -side left -sticky w
77 Scrollbar.rightarrow -side right -sticky e
78 Scrollbar.thumb -sticky ew
79 }
80 }
81 By default, the layout for a widget is the same as its class name.
83 Some widgets may override this (for example, the ttk::scrollbar widget
84 chooses different layouts based on the -orient option).
85
87 In standard Tk, many widgets have a -state option which (in most cases)
88 is either normal or disabled. Some widgets support additional states,
89 such as the entry widget which has a readonly state and the various
90 flavors of buttons which have active state.
91 The themed Tk widgets generalizes this idea: every widget has a bitmap
93 of independent state flags. Widget state flags include active, dis‐
94 abled, pressed, focus, etc., (see ttk::widget(n) for the full list of
95 state flags).
96 Instead of a -state option, every widget now has a state widget command
98 which is used to set or query the state. A state specification is a
99 list of symbolic state names indicating which bits are set, each op‐
100 tionally prefixed with an exclamation point indicating that the bit is
101 cleared instead.
102 For example, the class bindings for the ttk::button widget are:
104 bind TButton <Enter>{ %W state active }
106 bind TButton <Leave>{ %W state !active }
107 bind TButton <ButtonPress-1>{ %W state pressed }
108 bind TButton <Button1-Leave>{ %W state !pressed }
109 bind TButton <Button1-Enter>{ %W state pressed }
110 bind TButton <ButtonRelease-1>\
111 { %W instate {pressed} { %W state !pressed ; %W invoke } }
112 This specifies that the widget becomes active when the pointer enters
114 the widget, and inactive when it leaves. Similarly it becomes pressed
115 when the mouse button is pressed, and !pressed on the ButtonRelease
116 event. In addition, the button unpresses if pointer is dragged outside
117 the widget while Button-1 is held down, and represses if it's dragged
118 back in. Finally, when the mouse button is released, the widget's
119 -command is invoked, but only if the button is currently in the pressed
120 state. (The actual bindings are a little more complicated than the
121 above, but not by much).
122
124 Each widget is associated with a style, which specifies values for ele‐
125 ment options. Style names use a recursive dotted notation like layouts
126 and elements; by default, widgets use the class name to look up a style
127 in the current theme. For example:
128 ttk::style configure TButton \
130 -background #d9d9d9 \
131 -foreground black \
132 -relief raised \
133 ;
134 Many elements are displayed differently depending on the widget state.
136 For example, buttons have a different background when they are active,
137 a different foreground when disabled, and a different relief when
138 pressed. The style map command specifies dynamic option settings for a
139 particular style:
140 ttk::style map TButton \
142 -background [list disabled #d9d9d9 active #ececec] \
143 -foreground [list disabled #a3a3a3] \
144 -relief [list {pressed !disabled} sunken] \
145 ;
146
148 ttk::widget(n), ttk::style(n)
149Tk 8.5 ttk::intro(n)