|
 |
|
| |
Packing is affected by three parameters, which are the
same for both start and end packing; the meaning of
these parameters is somewhat complicated, because they
interact with the
homogeneous setting of the box and with each
other.
Here's how a GtkBox computes
its size request for the "interesting" direction (width
for GtkHBox, height for GtkVBox):
-
The total requested size of each child is
considered to be the child's size request, plus two
times the padding
value used to pack the child. A child's padding is the amount of
blank space on either side of it. In short, Child
Size = (Child Widget's Size Request) + 2*(Child
Padding).
-
If the box is homogeneous, the base size request
for the entire box is equal to the size (request +
padding) of the largest child, times the number of
children. In a homogeneous box, all children are as
large as the largest child.
-
If the box is not homogeneous, the base size
request for the entire box is the sum of the size
(request + padding) of each child.
-
The box-wide
spacing setting determines how much blank
space to leave between children; so this value is
multiplied by the number of chilren minus one, and
added to the base size request. Note that spacing does not belong to a child;
it is blank space between children and is
unaffected by the
expand and
fill parameters.
Padding, on the other hand, is the space around
each child and is affected
by the child's packing parameters.
-
All containers have a "border width" setting; two
times the border width is added to the request,
representing a border on either side. Thus, the
total size requested by a
GtkBox is: (Sum of Child Sizes) +
Spacing*(Number of Children - 1) + 2*(Border
Width).
After computing its size request and delivering it to
its parent container, GtkBox
will receive its size allocation and distribute it
among its children as follows:
-
Enough space for the border width and inter-child
spacing is subtracted from the allocation; the
remainder is the available space for children
themselves. This space is divided into two chunks:
the amount actually requested by the children
(child requisitions and padding), and the "extra."
Extra = (Allocation Size) - (Sum of Child
Sizes).
-
If the box is not homogeneous, the "extra" space is
divided among those children with the expand parameter set to TRUE. These children can
expand to fit available space. If no child can
expand, the extra is used to add more space in the
center of the box, between the start-packed widgets
and the end-packed widgets.
-
If the box is homogeneous, the extra is distributed
according to need; those children who requested
more space get less extra, so that everyone ends up
with the same amount of space. The expand parameter is ignored for
homogeneous boxes---extra is distributed to all
children, not just the expandable ones.
-
When a child gets some extra space, there are two
possibilities. More padding can be added around the
child, or the child widget itself can be expanded.
The fill parameter
determines which will happen. If TRUE, the child widget expands
to fill the space---that is, the entire space
becomes the child's allocation; if fill is FALSE, the child's padding is
increased to fill the space, and the child is
allocated only the space it requested. Note that
fill has no effect
if expand is set to
FALSE and the box
is not homogeneous, because the child will never
receive any extra space to fill.
Whew! Who wants to think about all that? Fortunately,
there are some common patterns of usage, so you don't
need to solve a multivariate equation to figure out how
to use the widget. The authors of the GTK+ Tutorial
boil things down nicely to five cases that occur in
practice; we'll follow in their footsteps here.
|
|
|
