In the (unusual) case that you want to add user interface
descriptions from multiple sources to the same Builder you can
call new() to get an empty builder and populate it by
(multiple) calls to add_from_file(),
add_from_resource() or
add_from_string().
A Builder holds a reference to all objects that it has constructed
and drops these references when it is finalized. This finalization can
cause the destruction of non-widget objects or widgets which are not
contained in a toplevel window. For toplevel windows constructed by a
builder, it is the responsibility of the user to call
Gtk::Window::destroy() to get rid of them and all the widgets
they contain.
The functions object() and
objects() can be used to access the widgets in
the interface by the names assigned to them inside the UI description.
Toplevel windows returned by these functions will stay around until the
user explicitly destroys them with Gtk::Window::destroy(). Other
widgets will either be part of a larger hierarchy constructed by the
builder (in which case you should not have to worry about their lifecycle),
or without a parent, in which case they have to be added to some container
to make use of them. Non-widget objects need to be reffed with
g_object_ref() to keep them beyond the lifespan of the builder.
Builder parses textual descriptions of user interfaces which are
specified in XML format. We refer to these descriptions as “GtkBuilder
UI definitions” or just “UI definitions” if the context is clear.
The toplevel element is <interface>. It optionally takes a “domain”
attribute, which will make the builder look for translated strings
using dgettext() in the domain specified. This can also be done by
calling set_translation_domain() on the builder.
Objects are described by <object> elements, which can contain
<property> elements to set properties, <signal> elements which
connect signals to handlers, and <child> elements, which describe
child objects (most often widgets inside a container, but also e.g.
actions in an action group, or columns in a tree model). A <child>
element contains an <object> element which describes the child object.
The target toolkit version(s) are described by <requires> elements,
the “lib” attribute specifies the widget library in question (currently
the only supported value is “gtk”) and the “version” attribute specifies
the target version in the form “<major>.<minor>”. Builder will
error out if the version requirements are not met.
Typically, the specific kind of object represented by an <object>
element is specified by the “class” attribute. If the type has not
been loaded yet, GTK tries to find the get_type() function from the
class name by applying heuristics. This works in most cases, but if
necessary, it is possible to specify the name of the get_type()
function explicitly with the “type-func” attribute.
Objects may be given a name with the “id” attribute, which allows the
application to retrieve them from the builder with
object(). An id is also necessary to use the
object as property value in other parts of the UI definition. GTK
reserves ids starting and ending with ___ (three consecutive
underscores) for its own purposes.
Setting properties of objects is pretty straightforward with the
<property> element: the “name” attribute specifies the name of the
property, and the content of the element specifies the value.
If the “translatable” attribute is set to a true value, GTK uses
gettext() (or dgettext() if the builder has a translation domain set)
to find a translation for the value. This happens before the value
is parsed, so it can be used for properties of any type, but it is
probably most useful for string properties. It is also possible to
specify a context to disambiguate short strings, and comments which
may help the translators.
Builder can parse textual representations for the most common
property types: characters, strings, integers, floating-point numbers,
booleans (strings like “TRUE”, “t”, “yes”, “y”, “1” are interpreted
as true, strings like “FALSE”, “f”, “no”, “n”, “0” are interpreted
as false), enumerations (can be specified by their name, nick or
integer value), flags (can be specified by their name, nick, integer
value, optionally combined with “|”, e.g.
“GTK_INPUT_HINT_EMOJI|GTK_INPUT_HINT_LOWERCASE”)
and colors (in a format understood by gdk::RGBA::parse()).
GVariants can be specified in the format understood by
g_variant_parse(), and pixbufs can be specified as a filename of an
image file to load.
Objects can be referred to by their name and by default refer to
objects declared in the local XML fragment and objects exposed via
expose_object(). In general, Builder allows
forward references to objects — declared in the local XML; an object
doesn’t have to be constructed before it can be referred to. The
exception to this rule is that an object has to be constructed before
it can be used as the value of a construct-only property.
It is also possible to bind a property value to another object’s
property value using the attributes “bind-source” to specify the
source object of the binding, and optionally, “bind-property” and
“bind-flags” to specify the source property and source binding flags
respectively. Internally, Builder implements this using GBinding
objects. For more information see g_object_bind_property().
Sometimes it is necessary to refer to widgets which have implicitly
been constructed by GTK as part of a composite widget, to set
properties on them or to add further children (e.g. the content area
of a Dialog). This can be achieved by setting the “internal-child”
property of the <child> element to a true value. Note that Builder
still requires an <object> element for the internal child, even if it
has already been constructed.
A number of widgets have different places where a child can be added
(e.g. tabs vs. page content in notebooks). This can be reflected in
a UI definition by specifying the “type” attribute on a <child>
The possible values for the “type” attribute are described in the
sections describing the widget-specific portions of UI definitions.
Signal handlers are set up with the <signal> element. The “name”
attribute specifies the name of the signal, and the “handler” attribute
specifies the function to connect to the signal.
The remaining attributes, “after”, “swapped” and “object”, have the
same meaning as the corresponding parameters of the
g_signal_connect_object() or g_signal_connect_data() functions. A
“last_modification_time” attribute is also allowed, but it does not
have a meaning to the builder.
If you rely on GModule support to lookup callbacks in the symbol table,
the following details should be noted:
When compiling applications for Windows, you must declare signal callbacks
with G_MODULE_EXPORT, or they will not be put in the symbol table.
On Linux and Unix, this is not necessary; applications should instead
be compiled with the -Wl,–export-dynamic CFLAGS, and linked against
gmodule-export-2.0.
Beyond this general structure, several object classes define their
own XML DTD fragments for filling in the ANY placeholders in the DTD
above. Note that a custom element in a element gets parsed by
the custom tag handler of the parent object, while a custom element in
an