Stacking Order (Geometry Management)
An application's Tk widgets belong to two hierarchies: one whose levels are ordered by the master/slave relationship, and another whose levels are ordered by the parent/child relationship.
Parent/Child Hierarchy and Stacking Order A widget's place in the parent/child hierarchy can be determined from the widget's name. The levels of the hierarchy are separated by dots in the widget name. For example, a widget .w1 is the parent of the widgets .w1.a, .w1.b, .w1.anything
The command
winfo children $widgetname
will return a list of the children of the widget $widgetname
The parent/child hierarchy is a convenient way to organise the naming of widgets; but it also determines the stacking order, whose effect on the appearance of a GUI application will be described later.
Master/Slave Hierarchy and Geometry Management
The master/slave hierarchy is defined by geometry management: if widget $A manages the geometry of widget $B, then $B is the slave of $A. Working out the hierarchy is a little complicated, because there is more than one geometry manager.
The command
winfo manager $B
returns the name of the geometry manager for $B - in plain Tcl/Tk the possible values are pack, grid, place, text and canvas. pack, grid, and place are full-featured geometry managers; text and canvas are classes of widget that have a limited capability to manage the geometry of widgets that are embedded in them. Add-ons to Tcl/Tk may provide alternative geometry managers, or indeed alternative widgets with geometry-management capability.
If $A uses the packer to manage $B, then the command
pack info $B
will return a list that begins
-in $A
followed by the other parameters used by the packer to manage $B
The command
pack slaves $A
will return a list of widgets, including $B, that are packed in $A
'insert note on canvas items'
Very often, the master/slave and parent/child hierarchies are the same: this is the case if an application has only one toplevel window ("."), and always uses the default master (the parent) in geometry management: for example
pack .frame.text
does not specify a master widget, and so the widget's parent, .frame, is used as the master.
If the programmer requires a different master, this may be specified with the pack option -in, or (indirectly) with the pack options -before or -after.
The master/slave hierarchy is an essential part of geometry management, and is the major factor that determines the layout of the widgets in a GUI application.
The parent/child hierarchy influences the widget layout in a more subtle way: the widget's place in the parent/child hierarchy influences its position in the stacking order of widgets.
The stacking order determines which widget is "on top of" which, and therefore which widget is visible when two or more widgets overlap.
(first draft by KJN)