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
gtk_widget_size_request(). 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 gtk_window_set_resizable()), 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
gtk_widget_size_allocate(). 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.

Child properties

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

gtk_container_add ()

Adds widget to container. Typically used for simple containers
such as GtkWindow, GtkFrame, or GtkButton; for more complicated
layout containers such as GtkBox or GtkTable, this function will
pick default packing parameters that may not be correct. So
consider functions such as gtk_box_pack_start() and
gtk_table_attach() as an alternative to gtk_container_add() 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.

gtk_container_remove ()

Removes widget from container. widget must be inside container.
Note that container will own a reference to widget, and that this
may be the last reference held; so removing a widget from its
container can destroy that widget. If you want to use widget
again, you need to add a reference to it while it's not inside
a container, using g_object_ref(). If you don't want to use widget
again it's usually more efficient to simply destroy it directly
using gtk_widget_destroy() since this will remove it from the
container and help break any circular reference count cycles.

gtk_container_forall ()

Invokes callback on 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 gtk_container_foreach(),
rather than gtk_container_forall().

gtk_container_set_border_width ()

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
GtkWindow; 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 GtkAlignment widget, call gtk_widget_set_usize() to give
it a size, and place it on the side of the container as a spacer.

gtk_container_propagate_expose ()

When a container receives an expose event, it must send synthetic
expose events to all children that don't have their own GdkWindows.
This function provides a convenient way of doing this. A container,
when it receives an expose event, calls gtk_container_propagate_expose()
once for each child, passing in the event the container received.

gtk_container_propagate_expose() takes care of deciding whether
an expose event needs to be sent to the child, intersecting
the event's area with the child area, and sending the event.

In most cases, a container can simply either simply inherit the
::expose implementation from GtkContainer, or, do some drawing
and then chain to the ::expose implementation from GtkContainer.

gtk_container_get_focus_chain ()

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, GTK+ stores NULL in
focusable_widgets and returns FALSE.

location to store the focus chain of the
container, or NULL. You should free this list
using g_list_free() when you are done with it, however
no additional reference count is added to the
individual widgets in the focus chain.

Returns :

TRUE if the focus chain of the container
has been set explicitly.

gtk_container_set_focus_chain ()

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.