1intro(n) Tile Widget Set intro(n)
2
6 tile_intro - Introduction to the Tile theme engine
7
9 The tile widget set is based on a revised and enhanced version of the
10 TIP #48 ⟨http://purl.org/tcl/tip/48⟩ style engine. The main concepts
11 are described below. The basic idea is to separate, to the extent pos‐
12 sible, the code implementing a widget's behavior from the code imple‐
13 menting its appearance. Widget class bindings are primarily responsi‐
14 ble for maintaining the widget state and invoking callbacks; all
15 aspects of the widgets appearance is
16
18 A theme is a collection of elements and styles that determine the look
19 and feel of the widget set. Themes can be used to:
20 · Isolate platform differences (X11 vs. classic Windows vs. XP vs.
22 Aqua ...)
23 · Adapt to display limitations (low-color, grayscale, monochrome,
25 tiny screens)
26 · Accessibility (high contrast, large type)
28 · Application suite "branding"
30 · Blend in with the rest of the desktop (Gnome, KDE, Java)
32 · And, of course: eye candy.
34
37 An element displays an individual part of a widget. For example, a
38 vertical scrollbar widget contains uparrow, downarrow, trough and
39 slider elements.
40 Element names use a recursive dotted notation. For example, uparrow
42 identifies a generic arrow element, and Scrollbar.arrow and Com‐
43 bobox.uparrow identify widget-specific elements. When looking for an
44 element, the style engine looks for the specific name first, and if an
45 element of that name is not found it looks for generic elements by
46 stripping off successive leading components of the element name.
47 Like widgets, elements have options which specify what to display and
49 how to display it. For example, the text element (which displays a
50 text string) has -text, -font, -foreground, -background, -underline,
51 and -width options. The value of an element resource is taken from:
52 · A dynamic setting specified by style map and the current state;
54 · An option of the same name and type in the widget containing the
56 element;
57 · The default setting specified by style default; or
59 · The element's built-in default value for the resource.
61
63 A layout specifies which elements make up a widget and how they are
64 arranged. The layout engine uses a simplified version of the pack
65 algorithm: starting with an initial cavity equal to the size of the
66 widget, elements are allocated a parcel within the cavity along the
67 side specified by the -side option, and placed within the parcel
68 according to the -sticky option. For example, the layout for a hori‐
69 zontal scrollbar style layout Horizontal.TScrollbar {
70 Scrollbar.trough -children { Scrollbar.leftarrow -side left
71 -sticky w Scrollbar.rightarrow -side right -sticky e Scroll‐
72 bar.thumb -side left -expand true -sticky ew
73 } } By default, the layout for a widget is the same as its class
74 name. Some widgets may override this (for example, the scrollbar wid‐
75 get chooses different layouts based on the -orient option).
76
79 In standard Tk, many widgets have a -state option which (in most cases)
80 is either normal or disabled. Some widgets support additional states,
81 such as the entry widget which has a readonly state and the various
82 flavors of buttons which have active state.
83 The Tile widget set generalizes this idea: every widget has a bitmap of
85 independent state flags. Widget state flags include active, disabled,
86 pressed, focus, etc., (see widget(n) for the full list of state flags).
87 Instead of a -state option, every widget now has a state widget command
89 which is used to set or query the state. A state specification is a
90 list of symbolic state names indicating which bits are set, each
91 optionally prefixed with an exclamation point indicating that the bit
92 is cleared instead.
93 For example, the class bindings for the tbutton widget are: bind TBut‐
95 ton <Enter> { %W state active } bind TButton <Leave> {
96 %W state !active } bind TButton <ButtonPress-1> { %W state pressed }
97 bind TButton <Button1-Leave> { %W state !pressed } bind TButton <But‐
98 ton1-Enter> { %W state pressed } bind TButton <ButtonRelease-1> \
99 { %W instate {pressed} { %W state !pressed ; %W invoke } } This
100 specifies that the widget becomes active when the pointer enters the
101 widget, and inactive when it leaves. Similarly it becomes pressed when
102 the mouse button is pressed, and !pressed on the ButtonRelease event.
103 In addition, the button unpresses if pointer is dragged outside the
104 widget while Button-1 is held down, and represses if it's dragged back
105 in. Finally, when the mouse button is released, the widget's -command
106 is invoked, but only if the button is currently in the pressed state.
107 (The actual bindings are a little more complicated than the above, but
108 not by much).
109 Note to self: rewrite that paragraph. It's horrible.
111
113 Each widget is associated with a style, which specifies values for ele‐
114 ment resources. Style names use a recursive dotted notation like lay‐
115 outs and elements; by default, widgets use the class name to look up a
116 style in the current theme. For example: style default TButton \
117 -background #d9d9d9 \ -foreground black \ -relief raised
118 \ ; Many elements are displayed differently depending on the wid‐
119 get state. For example, buttons have a different background when they
120 are active, a different foreground when disabled, and a different
121 relief when pressed. The style map command specifies dynamic resources
122 for a particular style: style map TButton \ -background [list dis‐
123 abled #d9d9d9 active #ececec] \ -foreground [list disabled
124 #a3a3a3] \ -relief [list {pressed !disabled} sunken] \ ;
125
127 widget(n), style(n), TIP #48 ⟨http://purl.org/tcl/tip/48⟩
128tile 0.2 intro(n)