/* GTK - The GIMP Toolkit * Copyright (C) 1998-2002 James Henstridge * Copyright (C) 2006-2007 Async Open Source, * Johan Dahlin , * Henrique Romano * * This library is free software; you can redistribute it and/or * modify it under the terms of the GNU Library General Public * License as published by the Free Software Foundation; either * version 2 of the License, or (at your option) any later version. * * This library is distributed in the hope that it will be useful, * but WITHOUT ANY WARRANTY; without even the implied warranty of * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU * Library General Public License for more details. * * You should have received a copy of the GNU Library General Public * License along with this library. If not, see . */ /** * SECTION:gtkbuilder * @Short_description: Build an interface from an XML UI definition * @Title: GtkBuilder * * A GtkBuilder is an auxiliary object that reads textual descriptions * of a user interface and instantiates the described objects. To create * a GtkBuilder from a user interface description, call * gtk_builder_new_from_file(), gtk_builder_new_from_resource() or * gtk_builder_new_from_string(). * * In the (unusual) case that you want to add user interface * descriptions from multiple sources to the same GtkBuilder you can * call gtk_builder_new() to get an empty builder and populate it by * (multiple) calls to gtk_builder_add_from_file(), * gtk_builder_add_from_resource() or gtk_builder_add_from_string(). * * A GtkBuilder 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_widget_destroy() * to get rid of them and all the widgets they contain. * * The functions gtk_builder_get_object() and gtk_builder_get_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_widget_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. * * The function gtk_builder_connect_signals() and variants thereof can be * used to connect handlers to the named signals in the description. * * # GtkBuilder UI Definitions # {#BUILDER-UI} * * GtkBuilder parses textual descriptions of user interfaces which are * specified in an XML format which can be roughly described by the * RELAX NG schema below. We refer to these descriptions as * “GtkBuilder UI definitions” or just * “UI definitions” if the context is clear. * Do not confuse GtkBuilder UI Definitions with * [GtkUIManager UI Definitions][XML-UI], which * are more limited in scope. It is common to use `.ui` * as the filename extension for files containing GtkBuilder UI * definitions. * * [RELAX NG Compact Syntax](https://git.gnome.org/browse/gtk+/tree/gtk/gtkbuilder.rnc) * * The toplevel element is . 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 gtk_builder_set_translation_domain() on the builder. * Objects are described by elements, which can contain * elements to set properties, elements which * connect signals to handlers, and 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 * element contains an element which describes the child object. * The target toolkit version(s) are described by 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 “.”. The builder will error * out if the version requirements are not met. * * Typically, the specific kind of object represented by an * 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 * explictly with the "type-func" attribute. As a special case, GtkBuilder * allows to use an object that has been constructed by a #GtkUIManager in * another part of the UI definition by specifying the id of the #GtkUIManager * in the “constructor” attribute and the name of the object in the “id” * attribute. * * Objects may be given a name with the “id” attribute, which allows the * application to retrieve them from the builder with gtk_builder_get_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 ___ (3 underscores) for its own purposes. * * Setting properties of objects is pretty straightforward with the * 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. * * GtkBuilder 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_VISIBLE|GTK_REALIZED”) * and colors (in a format understood by gdk_color_parse()). 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 * gtk_builder_expose_object(). * * In general, GtkBuilder 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. * * Signal handlers are set up with the element. The “name” * attribute specifies the name of the signal, and the “handler” attribute * specifies the function to connect to the signal. By default, GTK+ tries * to find the handler using g_module_symbol(), but this can be changed by * passing a custom #GtkBuilderConnectFunc to * gtk_builder_connect_signals_full(). 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. * * 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 @vbox of * a #GtkDialog). This can be achieved by setting the “internal-child” * propery of the element to a true value. Note that GtkBuilder * still requires an 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 * The possible values for the “type” attribute are described in the * sections describing the widget-specific portions of UI definitions. * * # A GtkBuilder UI Definition * * |[ * * * * * 10 * * * 20 * * * gtk-ok * TRUE * * * * * * * * * * ]| * * 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 element gets parsed by the custom tag handler of the object. * * These XML fragments are explained in the documentation of the * respective objects. * * Additionally, since 3.10 a special