18 Tk Fundamentals

"Hello, World!" Tk program.

#!/usr/local/bin/wish

button .hello -text Hello \

	-command {puts stdout "Hello, World!"}

pack .hello -padx 20 -pady 10

#!/usr/local/bin/wish

There are two Tcl commands in the script: one to create the button, and one to make it visible on the display. The button command creates an instance of a button:

button .hello -text Hello \

	-command {puts stdout "Hello, World!"}

The name of the button is .hello. The label on the button is Hello, and the command associated with the button is:

puts stdout "Hello, World!"

pack .hello -padx 20 -pady 10

Tk uses an object-based system for creating and naming widgets. Associated with each class of widget (e.g., Button) is a command that creates instances of that class of widget. As the widget is created, a new Tcl command is defined that operates on that instance of the widget. Example 18-1 creates a button named .hello, and we can operate on the button using its name as a Tcl command. For example, we can cause the button to highlight a few times:

.hello flash

.hello invoke

Tk has widget classes and instances, but it is not fully object oriented. It is not possible to subclass a widget class and use inheritance. Instead, Tk provides very flexible widgets that can be configured in many different ways to tune their appearance. The resource database can store configuration information that is shared by many widgets, and new classes can be introduced to group resources. Widget behavior is shared by using binding tags that group bindings. Instead of building class hierarchies, Tk uses composition to assemble widgets with shared behavior and attributes.

Naming Tk Widgets

Each component of a Tk pathname must start with a lowercase letter or a number. Obviously, a component cannot include a period, either. The lower case restriction avoids a conflict with resource class names that begin with an upper case letter. A resource name can include Tk pathname components and Tk widget classes, and case is used to distinguish them. Chapter 25 describes resources in detail.

Store widget names in variables.

There is one drawback to the Tk widget naming system. If your interface changes enough it can result in some widgets changing their position in the widget hierarchy. In that case they may need to change their name. You can insulate yourself from this programming nuisance by using variables to hold the names of important widgets. Use a variable reference instead of widget pathnames in case you need to change things, or if you want to reuse your code in a different interface.

Configuring Tk Widgets

Finally, each widget instance supports a configure operation, which can be abbreviated to config, that can query and change these attributes. The syntax for config uses the same named argument pairs used when you create the widget. For example, we can change the background color of the button to red even after it has been created and mapped onto the screen:

.hello config -background red

.hello config -text Goodbye! -command exit

.hello cget -background

You can find out more details about a widget attribute by using configure without a value:

.hello config -background

The returned information includes the command-line switch, the resource name, the class name, the default value, and the current value, which is last. The class and resource name have to do with the resource mechanism described in Chapter 25. If you only specify configure and no attribute, then a list of the configuration information for all widget attributes is returned. Example 18-2 uses this to print out all the information about a widget:

proc Widget_Attributes {w {out stdout}} {

	puts $out [format "%-20s %-10s %s" Attribute Default Value]

	foreach item [$w configure] {

		puts $out [format "%-20s %-10s %s" \

			[lindex $item 0] [lindex $item 3] \

			[lindex $item 4]]

	}

}

The tables in this book list widget attributes by their resource name.

You need to know these naming conventions if you specify widget attributes via the resource mechanism. The command-line option can be derived from the resource name by mapping it to all lowercase. The primary advantage of using resources to specify attributes is that you do not have to litter your code with attribute specifications. With just a few resource database entries you can specify attributes for all your widgets. In addition, if attributes are specified with resources, users can provide alternate resource specifications in order to override the values supplied by the application. For attributes like colors and fonts, this feature can be important to users. Resource specifications are described in detail in Chapter 25.

The Tk Manual Pages

% man button

There are a large number of attributes that are common across most of the Tk widgets. These are described in a separate man page under the name options. Each man page begins with a STANDARD OPTIONS section that lists which of these standard attributes apply, but you have to look at the options man page for the description. In contrast, the tables in this book always list all widget attributes.

Summary of the Tk Commands