pack

pack , a built-in Tk command, is one the Geometry managers provided by Tk.

Synopsis

pack slave ?slave ...? ?options?

pack configure slave ?slave ...? ?options?

pack forget slave ?slave ...?

pack info slave

pack propagate master ?boolean?

pack slaves master

Documentation

official reference

See also

tkPACK , A Demonstration of Packing Geometry Management in Tk

grid

gridplus

place

dpack

Smartpack

A little tool to help script hierarchies of frames using the pack layout manager.

Description

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.

A slave is a window.

pack creates a parcel for each slave that it manages, decides how to place and size the parcel, and then decides how to place and size the slave within that parcel. Parcels and slaves can be independently configured. For example, -expand configures the behaviour of a parcel while -fill configures the behaviour of a slave. These behaviours can be combined to achieve various effects.

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 makes 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 documentation fails to do adequately.

AET: Had terrible trouble understanding pack till reading Welch 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
pack {*}[winfo children .top] -side left
text   .t
label  .bottom -text "This goes below"
pack {*}[winfo children .] ;# -side top is default 

Notice the {*}winfo children pack idiom, which saves you keeping track of the children...

PYK 2016-02-22: Replaced eval with post-8.4 {*}winfo children in this example by RS.

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