GTK+ uses a height-for-width (and width-for-height) geometry management
system. Height-for-width means that a widget can change how much
vertical space it needs, depending on the amount of horizontal space
that it is given (and similar for width-for-height). The most common
example is a label that reflows to fill up the available width, wraps
to fewer lines, and therefore needs less height.
Height-for-width geometry management is implemented in GTK+ by way
of five virtual methods:
There are some important things to keep in mind when implementing
height-for-width and when using it in container implementations.
The geometry management system will query a widget hierarchy in
only one orientation at a time. When widgets are initially queried
for their minimum sizes it is generally done in two initial passes
in the #GtkSizeRequestMode chosen by the toplevel.
For example, when queried in the normal
gtk.types.SizeRequestMode.HeightForWidth mode:
First, the default minimum and natural width for each widget
in the interface will be computed using gtk.widget.Widget.getPreferredWidth.
Because the preferred widths for each container depend on the preferred
widths of their children, this information propagates up the hierarchy,
and finally a minimum and natural width is determined for the entire
toplevel. Next, the toplevel will use the minimum width to query for the
minimum height contextual to that width using
gtk.widget.Widget.getPreferredHeightForWidth, which will also be a highly
recursive operation. The minimum height for the minimum width is normally
used to set the minimum size constraint on the toplevel
(unless gtk.window.Window.setGeometryHints is explicitly used instead).
After the toplevel window has initially requested its size in both
dimensions it can go on to allocate itself a reasonable size (or a size
previously specified with gtk.window.Window.setDefaultSize). During the
recursive allocation process it’s important to note that request cycles
will be recursively executed while container widgets allocate their children.
Each container widget, once allocated a size, will go on to first share the
space in one orientation among its children and then request each child's
height for its target allocated width or its width for allocated height,
depending. In this way a #GtkWidget will typically be requested its size
a number of times before actually being allocated a size. The size a
widget is finally allocated can of course differ from the size it has
requested. For this reason, #GtkWidget caches a small number of results
to avoid re-querying for the same sizes in one allocation cycle.
See
[GtkContainer’s geometry management section][container-geometry-management]
to learn more about how height-for-width allocations are performed
by container widgets.
If a widget does move content around to intelligently use up the
allocated size then it must support the request in both
#GtkSizeRequestModes even if the widget in question only
trades sizes in a single orientation.
For instance, a #GtkLabel that does height-for-width word wrapping
will not expect to have #GtkWidgetClass.get_preferred_height() called
because that call is specific to a width-for-height request. In this
case the label must return the height required for its own minimum
possible width. By following this rule any widget that handles
height-for-width or width-for-height requests will always be allocated
at least enough space to fit its own content.
Here are some examples of how a gtk.types.SizeRequestMode.HeightForWidth widget
generally deals with width-for-height requests, for #GtkWidgetClass.get_preferred_height()
it will do:
staticvoid
foo_widget_get_preferred_height (GtkWidget *widget,
gint *min_height,
gint *nat_height)
{
if (i_am_in_height_for_width_mode)
{
gint min_width, nat_width;
GTK_WIDGET_GET_CLASS (widget)->get_preferred_width (widget,
&min_width,
&nat_width);
GTK_WIDGET_GET_CLASS (widget)->get_preferred_height_for_width
(widget,
min_width,
min_height,
nat_height);
}
else
{
... some widgets do both. For instance, if a GtkLabel is
rotated to 90 degrees it will return the minimum and
natural height for the rotated label here.
}
}
And in #GtkWidgetClass.get_preferred_width_for_height() it will simply return
the minimum and natural width:
staticvoid
foo_widget_get_preferred_width_for_height (GtkWidget *widget,
gint for_height,
gint *min_width,
gint *nat_width)
{
if (i_am_in_height_for_width_mode)
{
GTK_WIDGET_GET_CLASS (widget)->get_preferred_width (widget,
min_width,
nat_width);
}
else
{
... again if a widget is sometimes operating in
width-for-height mode (like a rotated GtkLabel) it can go
ahead and do its real width for height calculation here.
}
}
Often a widget needs to get its own request during size request or
allocation. For example, when computing height it may need to also
compute width. Or when deciding how to use an allocation, the widget
may need to know its natural size. In these cases, the widget should
be careful to call its virtual methods directly, like this:
It will not work to use the wrapper functions, such as
gtk.widget.Widget.getPreferredWidth inside your own size request
implementation. These return a request adjusted by #GtkSizeGroup
and by the #GtkWidgetClass.adjust_size_request() virtual method. If a
widget used the wrappers inside its virtual method implementations,
then the adjustments (such as widget margins) would be applied
twice. GTK+ therefore does not allow this and will warn if you try
to do it.
Of course if you are getting the size request for
another widget, such as a child of a
container, you must use the wrapper APIs.
Otherwise, you would not properly consider widget margins,
#GtkSizeGroup, and so forth.
Since 3.10 GTK+ also supports baseline vertical alignment of widgets. This
means that widgets are positioned such that the typographical baseline of
widgets in the same row are aligned. This happens if a widget supports baselines,
has a vertical alignment of gtk.types.Align.Baseline, and is inside a container
that supports baselines and has a natural “row” that it aligns to the baseline,
or a baseline assigned to it by the grandparent.
Baseline alignment support for a widget is done by the #GtkWidgetClass.get_preferred_height_and_baseline_for_width()
virtual function. It allows you to report a baseline in combination with the
minimum and natural height. If there is no baseline you can return -1 to indicate
this. The default implementation of this virtual function calls into the
#GtkWidgetClass.get_preferred_height() and #GtkWidgetClass.get_preferred_height_for_width(),
so if baselines are not supported it doesn’t need to be implemented.
If a widget ends up baseline aligned it will be allocated all the space in the parent
as if it was gtk.types.Align.Fill, but the selected baseline can be found via gtk.widget.Widget.getAllocatedBaseline.
If this has a value other than -1 you need to align the widget such that the baseline
appears at the position.
Style Properties
#GtkWidget introduces “style
properties” - these are basically object properties that are stored
not on the object, but in the style object associated to the widget. Style
properties are set in [resource files][gtk3-Resource-Files].
This mechanism is used for configuring such things as the location of the
scrollbar arrows through the theme, giving theme authors more control over the
look of applications without the need to write a theme engine in C.
The GtkWidget implementation of the GtkBuildable interface supports a
custom <accelerator> element, which has attributes named ”key”, ”modifiers”
and ”signal” and allows to specify accelerators.
An example of a UI definition fragment specifying an accelerator:
In addition to accelerators, GtkWidget also support a custom <accessible>
element, which supports actions and relations. Properties on the accessible
implementation of an object can be set by accessing the internal child
“accessible” of a #GtkWidget.
An example of a UI definition fragment specifying an accessible:
<objectclass="GtkLabel"id="label1"/><propertyname="label">I am a Label for a Button</property></object><objectclass="GtkButton"id="button1"><accessibility><actionaction_name="click"translatable="yes">Click the button.</action><relationtarget="label1"type="labelled-by"/></accessibility><childinternal-child="accessible"><objectclass="AtkObject"id="a11y-button1"><propertyname="accessible-name">Clickable Button</property></object></child></object>
Finally, GtkWidget allows style information such as style classes to
be associated with widgets, using the custom <style> element:
Building composite widgets from template XML ## {#composite-templates}
GtkWidget exposes some facilities to automate the procedure
of creating composite widgets using #GtkBuilder interface description
language.
To create composite widgets with #GtkBuilder XML, one must associate
the interface description with the widget class at class initialization
time using gtk.widget_class.WidgetClass.setTemplate.
The interface description semantics expected in composite template descriptions
is slightly different from regular #GtkBuilder XML.
Unlike regular interface descriptions, gtk.widget_class.WidgetClass.setTemplate will
expect a <template> tag as a direct child of the toplevel <interface>
tag. The <template> tag must specify the “class” attribute which must be
the type name of the widget. Optionally, the “parent” attribute may be
specified to specify the direct parent type of the widget type, this is
ignored by the GtkBuilder but required for Glade to introspect what kind
of properties and internal children exist for a given type when the actual
type does not exist.
The XML which is contained inside the <template> tag behaves as if it were
added to the <object> tag defining "widget" itself. You may set properties
on @widget by inserting <property> tags into the <template> tag, and also
add <child> tags to add children and extend "widget" in the normal way you
would with <object> tags.
Additionally, <object> tags can also be added before and after the initial
<template> tag in the normal way, allowing one to define auxiliary objects
which might be referenced by other widgets declared as children of the
<template> tag.
Typically, you'll place the template fragment into a file that is
bundled with your project, using #GResource. In order to load the
template, you need to call gtk.widget_class.WidgetClass.setTemplateFromResource
from the class initialization of your #GtkWidget type:
You can access widgets defined in the template using the
gtk.widget.Widget.getTemplateChild function, but you will typically declare
a pointer in the instance private data structure of your type using the same
name as the widget in the template definition, and call
gtk_widget_class_bind_template_child_private() with that name, e.g.
You can also use gtk_widget_class_bind_template_callback() to connect a signal
callback defined in the template with a function visible in the scope of the
class, e.g.
// the signal handler has the instance and user data swapped// because of the swapped="yes" attribute in the template XMLstaticvoid
hello_button_clicked (FooWidget *self,
GtkButton *button)
{
g_print ("Hello, world!\n");
}
staticvoid
foo_widget_class_init (FooWidgetClass *klass)
{
// ...
gtk_widget_class_set_template_from_resource (GTK_WIDGET_CLASS (klass),
"/com/example/ui/foowidget.ui");
gtk_widget_class_bind_template_callback (GTK_WIDGET_CLASS (klass), hello_button_clicked);
}
GtkWidget is the base class all widgets in GTK+ derive from. It manages the widget lifecycle, states and style.
Height-for-width Geometry Management # {#geometry-management}
GTK+ uses a height-for-width (and width-for-height) geometry management system. Height-for-width means that a widget can change how much vertical space it needs, depending on the amount of horizontal space that it is given (and similar for width-for-height). The most common example is a label that reflows to fill up the available width, wraps to fewer lines, and therefore needs less height.
Height-for-width geometry management is implemented in GTK+ by way of five virtual methods:
There are some important things to keep in mind when implementing height-for-width and when using it in container implementations.
The geometry management system will query a widget hierarchy in only one orientation at a time. When widgets are initially queried for their minimum sizes it is generally done in two initial passes in the #GtkSizeRequestMode chosen by the toplevel.
For example, when queried in the normal gtk.types.SizeRequestMode.HeightForWidth mode: First, the default minimum and natural width for each widget in the interface will be computed using gtk.widget.Widget.getPreferredWidth. Because the preferred widths for each container depend on the preferred widths of their children, this information propagates up the hierarchy, and finally a minimum and natural width is determined for the entire toplevel. Next, the toplevel will use the minimum width to query for the minimum height contextual to that width using gtk.widget.Widget.getPreferredHeightForWidth, which will also be a highly recursive operation. The minimum height for the minimum width is normally used to set the minimum size constraint on the toplevel (unless gtk.window.Window.setGeometryHints is explicitly used instead).
After the toplevel window has initially requested its size in both dimensions it can go on to allocate itself a reasonable size (or a size previously specified with gtk.window.Window.setDefaultSize). During the recursive allocation process it’s important to note that request cycles will be recursively executed while container widgets allocate their children. Each container widget, once allocated a size, will go on to first share the space in one orientation among its children and then request each child's height for its target allocated width or its width for allocated height, depending. In this way a #GtkWidget will typically be requested its size a number of times before actually being allocated a size. The size a widget is finally allocated can of course differ from the size it has requested. For this reason, #GtkWidget caches a small number of results to avoid re-querying for the same sizes in one allocation cycle.
See [GtkContainer’s geometry management section][container-geometry-management] to learn more about how height-for-width allocations are performed by container widgets.
If a widget does move content around to intelligently use up the allocated size then it must support the request in both #GtkSizeRequestModes even if the widget in question only trades sizes in a single orientation.
For instance, a #GtkLabel that does height-for-width word wrapping will not expect to have #GtkWidgetClass.get_preferred_height() called because that call is specific to a width-for-height request. In this case the label must return the height required for its own minimum possible width. By following this rule any widget that handles height-for-width or width-for-height requests will always be allocated at least enough space to fit its own content.
Here are some examples of how a gtk.types.SizeRequestMode.HeightForWidth widget generally deals with width-for-height requests, for #GtkWidgetClass.get_preferred_height() it will do:
And in #GtkWidgetClass.get_preferred_width_for_height() it will simply return the minimum and natural width:
Often a widget needs to get its own request during size request or allocation. For example, when computing height it may need to also compute width. Or when deciding how to use an allocation, the widget may need to know its natural size. In these cases, the widget should be careful to call its virtual methods directly, like this:
GTK_WIDGET_GET_CLASS(widget)->get_preferred_width (widget, &min, &natural);It will not work to use the wrapper functions, such as gtk.widget.Widget.getPreferredWidth inside your own size request implementation. These return a request adjusted by #GtkSizeGroup and by the #GtkWidgetClass.adjust_size_request() virtual method. If a widget used the wrappers inside its virtual method implementations, then the adjustments (such as widget margins) would be applied twice. GTK+ therefore does not allow this and will warn if you try to do it.
Of course if you are getting the size request for another widget, such as a child of a container, you must use the wrapper APIs. Otherwise, you would not properly consider widget margins, #GtkSizeGroup, and so forth.
Since 3.10 GTK+ also supports baseline vertical alignment of widgets. This means that widgets are positioned such that the typographical baseline of widgets in the same row are aligned. This happens if a widget supports baselines, has a vertical alignment of gtk.types.Align.Baseline, and is inside a container that supports baselines and has a natural “row” that it aligns to the baseline, or a baseline assigned to it by the grandparent.
Baseline alignment support for a widget is done by the #GtkWidgetClass.get_preferred_height_and_baseline_for_width() virtual function. It allows you to report a baseline in combination with the minimum and natural height. If there is no baseline you can return -1 to indicate this. The default implementation of this virtual function calls into the #GtkWidgetClass.get_preferred_height() and #GtkWidgetClass.get_preferred_height_for_width(), so if baselines are not supported it doesn’t need to be implemented.
If a widget ends up baseline aligned it will be allocated all the space in the parent as if it was gtk.types.Align.Fill, but the selected baseline can be found via gtk.widget.Widget.getAllocatedBaseline. If this has a value other than -1 you need to align the widget such that the baseline appears at the position.
Style Properties
#GtkWidget introduces “style properties” - these are basically object properties that are stored not on the object, but in the style object associated to the widget. Style properties are set in [resource files][gtk3-Resource-Files]. This mechanism is used for configuring such things as the location of the scrollbar arrows through the theme, giving theme authors more control over the look of applications without the need to write a theme engine in C.
Use gtk.widget_class.WidgetClass.installStyleProperty to install style properties for a widget class, gtk.widget_class.WidgetClass.findStyleProperty or gtk.widget_class.WidgetClass.listStyleProperties to get information about existing style properties and gtk.widget.Widget.styleGetProperty, gtk.widget.Widget.styleGet or gtk.widget.Widget.styleGetValist to obtain the value of a style property.
GtkWidget as GtkBuildable
The GtkWidget implementation of the GtkBuildable interface supports a custom <accelerator> element, which has attributes named ”key”, ”modifiers” and ”signal” and allows to specify accelerators.
An example of a UI definition fragment specifying an accelerator:
In addition to accelerators, GtkWidget also support a custom <accessible> element, which supports actions and relations. Properties on the accessible implementation of an object can be set by accessing the internal child “accessible” of a #GtkWidget.
An example of a UI definition fragment specifying an accessible:
Finally, GtkWidget allows style information such as style classes to be associated with widgets, using the custom <style> element:
Building composite widgets from template XML ## {#composite-templates}
GtkWidget exposes some facilities to automate the procedure of creating composite widgets using #GtkBuilder interface description language.
To create composite widgets with #GtkBuilder XML, one must associate the interface description with the widget class at class initialization time using gtk.widget_class.WidgetClass.setTemplate.
The interface description semantics expected in composite template descriptions is slightly different from regular #GtkBuilder XML.
Unlike regular interface descriptions, gtk.widget_class.WidgetClass.setTemplate will expect a <template> tag as a direct child of the toplevel <interface> tag. The <template> tag must specify the “class” attribute which must be the type name of the widget. Optionally, the “parent” attribute may be specified to specify the direct parent type of the widget type, this is ignored by the GtkBuilder but required for Glade to introspect what kind of properties and internal children exist for a given type when the actual type does not exist.
The XML which is contained inside the <template> tag behaves as if it were added to the <object> tag defining "widget" itself. You may set properties on @widget by inserting <property> tags into the <template> tag, and also add <child> tags to add children and extend "widget" in the normal way you would with <object> tags.
Additionally, <object> tags can also be added before and after the initial <template> tag in the normal way, allowing one to define auxiliary objects which might be referenced by other widgets declared as children of the <template> tag.
An example of a GtkBuilder Template Definition:
Typically, you'll place the template fragment into a file that is bundled with your project, using #GResource. In order to load the template, you need to call gtk.widget_class.WidgetClass.setTemplateFromResource from the class initialization of your #GtkWidget type:
You will also need to call gtk.widget.Widget.initTemplate from the instance initialization function:
You can access widgets defined in the template using the gtk.widget.Widget.getTemplateChild function, but you will typically declare a pointer in the instance private data structure of your type using the same name as the widget in the template definition, and call gtk_widget_class_bind_template_child_private() with that name, e.g.
You can also use gtk_widget_class_bind_template_callback() to connect a signal callback defined in the template with a function visible in the scope of the class, e.g.