A Gtk+ user interface is constructed by nesting widgets inside widgets.
Container widgets are the inner nodes in the resulting tree of widgets: they
contain other widgets. So, for example, you might have a Window containing
a Frame containing a Label. If you wanted an image instead of a textual
label inside the frame, you might replace the Label widget with a Image
widget.

There are two major kinds of container widgets in Gtk+. Both are
subclasses of the abstract Container base class.

The first type of container widget has a single child widget and derives
from Bin. These containers are decorators, which add some kind of
functionality to the child. For example, a Button makes its child into a
clickable button; a Frame draws a frame around its child and a Window
places its child widget inside a top-level window.

The second type of container can have more than one child; its purpose is
to manage layout. This means that these containers assign sizes and
positions to their children. For example, a HBox arranges its children in
a horizontal row, and a Table arranges the widgets it contains in a
two-dimensional grid.

To fulfill its task, a layout container must negotiate the size
requirements with its parent and its children. This negotiation is carried
out in two phases, size requisition and size allocation.

The size requisition of a widget is it's desired width and height. This
is represented by a Requisition.

How a widget determines its desired size depends on the widget. A
Label, for example, requests enough space to display all its text.
Container widgets generally base their size request on the requisitions of
their children.

The size requisition phase of the widget layout process operates
top-down. It starts at a top-level widget, typically a Window. The
top-level widget asks its child for its size requisition by calling
widgetSizeRequest. To determine its requisition, the child asks its own
children for their requisitions and so on. Finally, the top-level widget
will get a requisition back from its child.

When the top-level widget has determined how much space its child would
like to have, the second phase of the size negotiation, size allocation,
begins. Depending on its configuration (see windowSetResizable), the
top-level widget may be able to expand in order to satisfy the size request
or it may have to ignore the size request and keep its fixed size. It then
tells its child widget how much space it gets by calling
widgetSizeAllocate. The child widget divides the space among its children
and tells each child how much space it got, and so on. Under normal
circumstances, a Window will always give its child the amount of space the
child requested.

A child's size allocation is represented by an Allocation.
This contains not only a width and height, but also a
position (i.e. X and Y coordinates), so that containers can tell their
children not only how much space they have gotten, but also where they are
positioned inside the space available to the container.

Widgets are required to honor the size allocation they receive; a size
request is only a request, and widgets must be able to cope with any size.

Container introduces child attributes - these are object attributes
that are not specific to either the container or the contained widget, but
rather to their relation. Typical examples of child attributes are the
position or pack-type of a widget which is contained in a Box.

The Container class does not itself define any child attributes, they are
defined (and documented) by the various Container subclasses.

Child attributes can be set or obtained in a similar way to ordinary
attributes. So ordinary attributes are set like so:

Adds widget to the container. Typically used for simple containers such
as Window, Frame, or Button; for more complicated layout containers
such as Box or Table, this function will pick default packing parameters
that may not be correct. So consider functions such as boxPackStart and
tableAttach as an alternative to containerAdd in those cases. A widget
may be added to only one container at a time; you can't place the same
widget inside two different containers.

Maps callback over each child of container, including children that
are considered "internal" (implementation details of the container).
"Internal" children generally weren't added by the user of the container,
but were added by the container implementation itself. Most applications
should use containerForeach, rather than containerForall.

Sets a focus chain, overriding the one computed automatically by Gtk+.

In principle each widget in the chain should be a descendant of the
container, but this is not enforced by this method, since it's allowed to
set the focus chain before you pack the widgets, or have a widget in the
chain that isn't always packed. The necessary checks are done when the focus
chain is actually traversed.

Retrieves the focus chain of the container, if one has been set
explicitly. If no focus chain has been explicitly set, Gtk+ computes the
focus chain based on the positions of the children. In that case the
function returns Nothing.

Hooks up an adjustment to focus handling in a container, so when a child
of the container is focused, the adjustment is scrolled to show that widget.
This function sets the vertical alignment. See
scrolledWindowGetVAdjustment for a typical way of obtaining the adjustment
and containerSetFocusHAdjustment for setting the horizontal adjustment.

The adjustments have to be in pixel units and in the same coordinate
system as the allocation for immediate children of the container.

Hooks up an adjustment to focus handling in a container, so when a child
of the container is focused, the adjustment is scrolled to show that widget.
This function sets the horizontal alignment. See
scrolledWindowGetHAdjustment for a typical way of obtaining the adjustment
and containerSetFocusVAdjustment for setting the vertical adjustment.

The adjustments have to be in pixel units and in the same coordinate
system as the allocation for immediate children of the container.

The border width of a container is the amount of space to leave around
the outside of the container. The only exception to this is Window;
because toplevel windows can't leave space outside, they leave the space
inside. The border is added on all sides of the container. To add space to
only one side, one approach is to create a Alignment widget, call
widgetSetUsize to give it a size, and place it on the side of the
container as a spacer.