See http://www.tcl.tk/software/plugin/contrib/packLet.html for an interactive demo.

HJG 2005-06-21 /usr/local/web/docs.main/products/tcltk/plugin/contrib/packLet.tcl": no such file or directory

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.

AET: Had terrible trouble understanding pack till reading Walsh et al's "Practical Programming in Tcl and Tk", which makes it clear. Once you get your head around it, it is very quick to use.

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...

LV Anyone have a pointer to a wiki page that describes the notation used for screen distances as used by pack's -pad type options? I see values like 2, .5c, 7m and so forth. Where do I read about the valid values? EKB I was just wondering the same thing! I made a page for screen distances.

See also

• grid
• gridplus
• place
• dpack