pack slave ?slave ...? ?options?
pack configure slave ?slave ...? ?options?
pack forget slave ?slave ...?
pack info slave
pack propagate master ?boolean?
pack slaves master
pack slave ?slave ...? ?options?
If the first argument to pack is a window name (any value starting with "."), then the command is processed in the same way as pack configure.
pack is one of several Geometry managers supported by Tk.
http://www.purl.org/tcl/home/man/tcl8.4/TkCmd/pack.html
Geometry management is an aspect of programming where personal style seems to dominate. That is, given the same lay description of a desired appearance, some programmers will use pack, some grid, some will reach for SpecTcl, and so on. Joe English, for example, has written
pack works best for me if the layout is "mostly vertical"
or "mostly horizontal" and there is exactly one main "work area"
that expands to fill all remaining available space. The rule
of thumb is to pack the "top stuff" first (menubar, toolbars),
with -expand false -fill x, the "bottom stuff" second (status
bar, command button box) with -expand false -fill x, and the
work area last with -expand true -fill both. Similarly
for horizontal layouts, but using -fill y for the "left stuff"
and "right stuff".
If there's a mixture of horizontal and vertical layouts,
I create subframes when changing orientation.while David Cuthbert's experience teaches him that
For me, it's not natural to design an interface according to pack
This is not a terribly unusual layout; nonetheless, I'd have a somewhat
difficult time describing it in terms of pack (e.g., which side to I
tell the message widget to pack to? How many frame containers do I
need?).
Discovering that a particular widget (or group of widgets) needs to go
into a frame is especially painful; suddenly, the widget gets a new
name, which must be propagated throughout (unless during my prototyping
I had the foresight to keep it all in a variable, but...).
So that's why I rely on grid. Discovering that I need another row or
column means I have to change the layout code, but not much else. No
new widgets, etc.EE: Actually, while I agree that having to put things into frames just to make them align the way I want is an inconvenience, it doesn't have to change the names of the widgets. You can just create the new frame as a sibling of the widgets it needs to contain, and [pack $top.w -in $top.frame].
Roy Terry is among pack's fans who emphasizes that it's like Tcl itself--it make people who expect it to be something other than what it is unhappy. He underscores the importance of "distinguishing between parcel space (-expand) and widget/slave (-fill)", which the current (8.4) documentation fails to do adequately.
RS If one dimension is good enough for me, I still often use pack. Here's a simple "2-D" example with a subframe, as mentioned above:
frame .top label .top.1 -text Hello button .top.2 -text world -command exit eval pack [winfo children .top] -side left text .t label .bottom -text "This goes below" eval pack [winfo children .] ;# -side top is default
Notice the eval pack idiom, which saves you keeping track of the children...
Category Command - Tk syntax help - Arts and Crafts of Tcl-Tk Programming