The class hierarchy looks complicated, but in actual practice, application programmers almost always refer to the classes at the very bottom of the hierarchy.
To make use of this reference material, there will be times when you will need to know how to read short passages of Tk and how to identify the various parts of a Tk command. (See section 20.1.4 for the Tkinter equivalents of what's below.)
Tk scripts are Tcl programs. Like all Tcl programs, Tk scripts are just lists of tokens separated by spaces. A Tk widget is just its class, the options that help configure it, and the actions that make it do useful things.
To make a widget in Tk, the command is always of the form:
classCommand newPathname options
.(period) and children are delimited by more periods. For example,
.myApp.controlPanel.okButtonmight be the name of a widget.
button .fred -fg red -text "hi there" ^ ^ \_____________________/ | | | class new options command widget (-opt val -opt val ...)
Once created, the pathname to the widget becomes a new command. This new widget command is the programmer's handle for getting the new widget to perform some action. In C, you'd express this as someAction(fred, someOptions), in C++, you would express this as fred.someAction(someOptions), and in Tk, you say:
.fred someAction someOptions
Note that the object name,
.fred, starts with a dot.
As you'd expect, the legal values for someAction will depend on
the widget's class:
.fred disable works if fred is a
button (fred gets greyed out), but does not work if fred is a label
(disabling of labels is not supported in Tk).
The legal values of someOptions is action dependent. Some
disable, require no arguments, others, like
a text-entry box's
delete command, would need arguments
to specify what range of text to delete.
See About this document... for information on suggesting changes.