Pack is the oldest general purpose geometry managers in Tk.
»Pack« operates on a spatial geometry model. Any window managed by »pack« is oriented toward a side or corner of its container window – mostly the parent window. This allows for surprisingly simple configuration code, but it’s also a stark limitation layout-vise! See Figure 4.2, “Pack is Spatial Oriented”
The three frames in Figure 4.2, “Pack is Spatial Oriented”
are packed in the following order: »black« -side
left -fill y
, »gray« -side top -fill
x
and »red« -side bottom
.
Expand is set to »1« for red.
At most, three windows can be layouted
inside a single region through »pack«.
Re-packing »black« –with the same geometry options– produces the design of Figure 4.4, “Black Re-packed”. Pack is a non-commutative geometry manager. The layout is a function from when the window was put under pack’s supervision and its configuration.
Suppose: You wanted your own version of Rtl_gridwin with pack as the favorite geometry manager.
The black, gray and red example is almost there; only on the wrong sides; and black and gray should not touch. Within Jeszra drag gray and then the red window onto the parent window. Now the layout resembles Figure 4.2, “Pack is Spatial Oriented”. It is still needed to tell black to vacant the height of gray on top. This is done through the geometry property »pady«. Setting pady to »20 0« will tell black to yield 20 pixels on top and none at the bottom.
»pady« and »padx« are read-only inside the Inspector. You have to make them writable again in order to perform these steps.
Flaws with Pack-Rtl_gridwin
Assuming black and gray represent scrollbars. Solution: change the packing sides for all windows; black to »right«, gray to »bottom« and red to »top«.
Coding would be required to set pady: For each resize event on gray; even before managing its geometry.
Example 4.6. Query Size before Management
scrollbar .gray -orient horizontal
scrollbar .black
some-window .red
# make the geometry management.
pack .black \
-side right -fill y \
-pady [list [winfo reqheight .gray] 0]
pack .gray -side bottom -fill x
pack .red -side top -fill both -expand 1
bind .gray < Configure > {
pack configure .black \
-pady [list [winfo height .gray] 0]
}
Although, the Example 4.6, “Query Size before Management” would do the job, it’s awkward!
The geometry manager pack is suitable for ragged designs, without interactive layout changes. It could be used for »OK«, »Cancel«, »Abort«, »Retry« , »Yes« and »No« button bars, at the bottom of a dialog. However, when the resulting dialog is to be deployed under different windowing systems: Pack is ill fitted for the job.
Much more complex designs are still possible with pack, but this requires a more complex window structure. That is: Additional containers have to be introduced, just for geometry management. As a rule of thumb: deeper window hierarchies are less flexible than flat ones.
Flat hierarchies are very relevant for striped interfaces, since each partly visible container must be striped, too. Hence, the graphical workload correlates with the window structure.