/* 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 . */ /** * GtkBuilder: * * A `GtkBuilder` reads XML descriptions of a user interface and * instantiates the described objects. * * To create a `GtkBuilder` from a user interface description, call * [ctor@Gtk.Builder.new_from_file], [ctor@Gtk.Builder.new_from_resource] * or [ctor@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 [ctor@Gtk.Builder.new] to get an empty builder and populate it by * (multiple) calls to [method@Gtk.Builder.add_from_file], * [method@Gtk.Builder.add_from_resource] or * [method@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 * [method@Gtk.Window.destroy] to get rid of them and all the widgets * they contain. * * The functions [method@Gtk.Builder.get_object] and * [method@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 [method@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. * * ## GtkBuilder UI Definitions * * `GtkBuilder` 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. * * ### Structure of UI definitions * * UI definition files are always encoded in UTF-8. * * 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 [method@Gtk.Builder.set_translation_domain] on the builder. * For example: * * ```xml * * * ... * * ``` * * ### Requirements * * 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 “``.``”. `GtkBuilder` will * error out if the version requirements are not met. For example: * * ```xml * * * * * ``` * * ### Objects * * Objects are defined as children of the `` element. * * 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. * * 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 explicitly with the "type-func" attribute. If your UI definition * is referencing internal types, you should make sure to call * `g_type_ensure()` for each object type before parsing the UI definition. * * Objects may be given a name with the “id” attribute, which allows the * application to retrieve them from the builder with * [method@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 `___` (three consecutive * underscores) for its own purposes. * * ### Properties * * 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: * * ```xml * * Hello, world * * ``` * * 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: * * ```xml * * Hello, world * * ``` * * `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 values, strings like “FALSE”, “f”, “no”, “n”, “0” are interpreted * as false values) * - enumeration types (can be specified by their full C identifier their short * name used when registering the enumeration type, or their integer value) * - flag types (can be specified by their C identifier, short name, integer * value, and optionally combined with “|” for bitwise OR, e.g. * “GTK_INPUT_HINT_EMOJI|GTK_INPUT_HINT_LOWERCASE”, or “emoji|lowercase”) * - colors (in a format understood by [method@Gdk.RGBA.parse]) * - `GVariant` (can be specified in the format understood by * [func@GLib.Variant.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 * [method@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. * * ### Property bindings * * 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, `GtkBuilder` implements this using * [class@GObject.Binding] objects. * * For instance, in the example below the “label” property of the * `bottom_label` widget is bound to the “label” property of the * `top_button` widget: * * ```xml * * vertical * * * Hello, world * * * * * * * * * ``` * * For more information, see the documentation of the * [method@GObject.Object.bind_property] method. * * ### Internal children * * 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 `GtkDialog`). This can be achieved by setting the “internal-child” * property 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. * * ### Specialized children * * 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. * * ### Signal handlers and function pointers * * 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. * * ```xml * * * * ``` * * The remaining attributes, “after”, “swapped” and “object”, have the * same meaning as the corresponding parameters of the * [func@GObject.signal_connect_object] or [func@GObject.signal_connect_data] * functions: * * - “after” matches the `G_CONNECT_AFTER` flag, and will ensure that the * handler is called after the default class closure for the signal * - “swapped” matches the `G_CONNECT_SWAPPED` flag, and will swap the * instance and closure arguments when invoking the signal handler * - “object” will bind the signal handler to the lifetime of the object * referenced by the attribute * * By default "swapped" will be set to "yes" if not specified otherwise, in * the case where "object" is set, for convenience. A “last_modification_time” * attribute is also allowed, but it does not have a meaning to the builder. * * When compiling applications for Windows, you must declare signal callbacks * with the `G_MODULE_EXPORT` decorator, or they will not be put in the symbol * table: * * ```c * G_MODULE_EXPORT void * hello_button__clicked (GtkButton *button, * gpointer data) * { * // ... * } * ``` * * On Linux and Unix, this is not necessary; applications should instead * be compiled with the `-Wl,--export-dynamic` argument inside their compiler * flags, and linked against `gmodule-export-2.0`. * * ## Example UI Definition * * ```xml * * * * * * * * * _Ok * True * * * * * * * * * * ``` * * ## Using GtkBuildable for extending UI definitions * * Objects can implement the [iface@Gtk.Buildable] interface to add custom * elements and attributes to the XML. Typically, any extension will be * documented in each type that implements the interface. * * ## Templates * * When describing a [class@Gtk.Widget], you can use the `