GtkContainer implements
AtkImplementorIface and GtkBuildable.
Detailed Description
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 GtkWindow
containing a GtkFrame containing a GtkLabel. If you wanted an image instead
of a textual label inside the frame, you might replace the GtkLabel widget
with a GtkImage widget.
There are two major kinds of container widgets in GTK+. Both are subclasses
of the abstract GtkContainer base class.
The first type of container widget has a single child widget and derives
from GtkBin. These containers are decorators, which
add some kind of functionality to the child. For example, a GtkButton makes
its child into a clickable button; a GtkFrame draws a frame around its child
and a GtkWindow 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 GtkHBox arranges its
children in a horizontal row, and a GtkTable 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.
Size Requisition
The size requisition of a widget is it's desired width and height.
This is represented by a GtkRequisition.
How a widget determines its desired size depends on the widget.
A GtkLabel, 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 GtkWindow. The top-level widget
asks its child for its size requisition by calling gtkWidgetSizeRequest.
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.
Size Allocation
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 gtkWindowSetResizable), 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 gtkWidgetSizeAllocate.
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 GtkWindow
will always give its child the amount of space the child requested.
A child's size allocation is represented by a GtkAllocation. This struct
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.
The GtkContainer implementation of the GtkBuildable interface
supports a element for children, which can
contain multiple elements that specify
child properties for the child.
Child properties in UI definitions
Since 2.16, child properties can also be marked as translatable using
the same "translatable", "comments" and "context" attributes that are used
for regular properties.