Table of Contents

_________________________________________________________________

Name

tile_intro - Introduction to the Tile theme engine _________________________________________________________________

Overview

The tile widget set is based on a revised and enhanced version of the TIP #48 style engine. The main concepts are described below. The basic idea is to separate, to the extent possible, the code implementing a widget's behavior from the code implementing its appearance. Wid- get class bindings are primarily responsible for maintain- ing the widget state and invoking callbacks; all aspects of the widgets appearance is

Themes

A theme is a collection of elements and styles that deter- mine the look and feel of the widget set. Themes can be used to:

·
Isolate platform differences (X11 vs. classic Win- dows vs. XP vs. Aqua ...)
·
Adapt to display limitations (low-color, grayscale, monochrome, tiny screens)
·
Accessibility (high contrast, large type)
·
Application suite branding"
·
Blend in with the rest of the desktop (Gnome, KDE, Java)
·
And, of course: eye candy.

Elements

An element displays an individual part of a widget. For example, a vertical scrollbar widget contains uparrow, downarrow, trough and slider elements.

Element names use a recursive dotted notation. For exam- ple, uparrow identifies a generic arrow element, and Scrollbar.arrow and Combobox.uparrow identify widget-spe- cific elements. When looking for an element, the style engine looks for the specific name first, and if an ele- ment of that name is not found it looks for generic ele- ments by stripping off successive leading components of the element name.

Like widgets, elements have options which specify what to display and how to display it. For example, the text ele- ment (which displays a text string) has -text, -font, -foreground, -background, -underline, and -width options. The value of an element resource is taken from:

·
A dynamic setting specified by style map and the current state;
·
An option of the same name and type in the widget containing the element;
·
The default setting specified by style default; or
·
The element's built-in default value for the resource.

Layouts

A layout specifies which elements make up a widget and how they are arranged. The layout engine uses a simplified version of the pack algorithm: starting with an initial cavity equal to the size of the widget, elements are allo- cated a parcel within the cavity along the side specified by the -side option, and placed within the parcel accord- ing to the -sticky option. For example, the layout for a horizontal scrollbar
style layout Horizontal.TScrollbar { Scrollbar.trough -children {
Scrollbar.leftarrow -side left -sticky w Scrollbar.rightarrow -side right -sticky e Scrollbar.thumb -side left -expand true -sticky ew }
}
By default, the layout for a widget is the same as its class name. Some widgets may override this (for example, the scrollbar widget chooses different layouts based on the -orient option).

States

In standard Tk, many widgets have a -state option which (in most cases) is either normal or disabled. Some wid- gets support additional states, such as the entry widget which has a readonly state and the various flavors of but- tons which have active state.

The Tile widget set generalizes this idea: every widget has a bitmap of independent state flags. Widget state flags include active, disabled, pressed, focus, etc., (see widget(n) for the full list of state flags).

Instead of a -state option, every widget now has a state widget command which is used to set or query the state. A state specification is a list of symbolic state names indicating which bits are set, each optionally prefixed with an exclamation point indicating that the bit is cleared instead.

For example, the class bindings for the tbutton widget are:
bind TButton <Enter>{ %W state active } bind TButton <Leave>{ %W state !active } bind TButton <ButtonPress-1>{ %W state pressed } bind TButton <Button1-Leave>{ %W state !pressed } bind TButton <Button1-Enter>{ %W state pressed } bind TButton <ButtonRelease-1>\
{ %W instate {pressed} { %W state !pressed ; %W invoke } } This specifies that the widget becomes active when the pointer enters the widget, and inactive when it leaves. Similarly it becomes pressed when the mouse button is pressed, and !pressed on the ButtonRelease event. In addition, the button unpresses if pointer is dragged out- side the widget while Button-1 is held down, and represses if it's dragged back in. Finally, when the mouse button is released, the widget's -command is invoked, but only if the button is currently in the pressed state. (The actual bindings are a little more complicated than the above, but not by much).

Note to self: rewrite that paragraph. It's horrible.

Styles

Each widget is associated with a style, which specifies values for element resources. Style names use a recursive dotted notation like layouts and elements; by default, widgets use the class name to look up a style in the cur- rent theme. For example:
style default TButton \
-background #d9d9d9 \
-foreground black \
-relief raised \
;
Many elements are displayed differently depending on the widget state. For example, buttons have a different back- ground when they are active, a different foreground when disabled, and a different relief when pressed. The style map command specifies dynamic resources for a particular style:
style map TButton \
-background [list disabled #d9d9d9 active #ececec] \ -foreground [list disabled #a3a3a3] \ -relief [list {pressed !disabled} sunken] \ ;

See Also

widget(n) , style(n) , TIP #48

Table of Contents