Package: gtk

Class gtk:builder

Superclasses

gobject:object, common-lisp:standard-object, common-lisp:t

Documented Subclasses

None

Direct Slots

translation-domain
The translation-domain property of type :string (Read / Write)
The translation domain used when translating property values that have been marked as translatable in interface descriptions. If the translation domain is nil, the gtk:builder object uses GNU gettext, otherwise GLIB gettext.
Default value: nil

Details

The gtk:builder object is an auxiliary object that reads textual descriptions of a user interface and instantiates the described objects. To create a gtk:builder object from a user interface description, call the gtk:builder-new-from-file, gtk:builder-new-from-resource or gtk:builder-new-from-string functions.

In the (unusual) case that you want to add user interface descriptions from multiple sources to the same gtk:builder object you can call the gtk:builder-new function to get an empty builder and populate it by (multiple) calls to the gtk:builder-add-from-file, gtk:builder-add-from-resource or gtk:builder-add-from-string functions.

A gtk:builder object 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 the gtk:widget-destroy function to get rid of them and all the widgets they contain.

The gtk:builder-object and gtk:builder-objects functions 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 the gtk:widget-destroy function. 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 life cycle, or without a parent, in which case they have to be added to some container to make use of them.

The gtk:builder-connect-signals function can be used to connect handlers to the named signals in the UI description.

GtkBuilder UI Definitions

The gtk:builder implementation parses textual descriptions of user interfaces which are specified in an XML format which can be roughly described by the RELAX NG Compact Syntax. We refer to these descriptions as gtk:builder UI definitions or just UI definitions if the context is clear. Do not confuse gtk:builder UI Definitions with the deprecated gtk:ui-manager UI Definitions, which are more limited in scope. It is common to use .ui as the filename extension for files containing gtk:builder UI definitions.

The toplevel element is <interface>. It optionally takes a "domain" attribute, which will make the builder look for translated strings using GNU gettext in the domain specified. This can also be done by calling the gtk:builder-translation-domain function 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, for example, 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>". The 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() 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() explictly with the "type-func" attribute. As a special case, the gtk:builder implementation allows to use an object that has been constructed by a gtk:ui-manager object in another part of the UI definition by specifying the ID of the gtk:ui-manager object in the "constructor" attribute and the name of the object in the "id" attribute.

Objects must be given a name with the "ID" attribute, which allows the application to retrieve them from the builder with the gtk:builder-object function. 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 <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 GNU gettext 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.

The gtk:builder implementation 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 "|", for example, "GTK_VISIBLE | GTK_REALIZED", and colors, in a format understood by the gdk:rgba-parse function. A g:variant parameter can be specified in the format understood by the g:variant-parse function, 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 the gtk:builder-expose-object function. In general, the gtk:builder implementation allows forward references to objects - declared in the local XML. An object does not 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, "bind-property" to specify the source property and optionally "bind-flags" to specify the binding flags. Internally the builder implements this using g:binding objects. For more information see the g:object-bind-property function.

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. Use the gtk:builder-connect-signals function to connect Lisp callback functions to the signal handlers. The remaining attributes, "after", "swapped" and "object", have the same meaning as the corresponding parameters of the g:signal-connect function. 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, for example, the vbox of a gtk:dialog widget. This can be achieved by setting the "internal-child" propery of the <child> element to a true value. Note that a gtk:builder object 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, for example, tabs versus 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.

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 <child> element gets parsed by the custom tag handler of the parent object, while a custom element in an <object> 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 <template> tag has been added to the format allowing one to define a widget class's components.

Examples

A gtk:builder UI Definition
<interface>
  <object class="GtkDialog" id="dialog1">
    <child internal-child="vbox">
      <object class="GtkVBox" id="vbox1">
        <property name="border-width">10</property>
        <child internal-child="action_area">
          <object class="GtkHButtonBox" id="hbuttonbox1">
            <property name="border-width">20</property>
            <child>
              <object class="GtkButton" id="ok_button">
                <property name="label">gtk-ok</property>
                <property name="use-stock">TRUE</property>
                <signal name="clicked" handler="ok_button_clicked"/>
              </object>
            </child>
          </object>
        </child>
      </object>
    </child>
  </object>
</interface>    
 

Returned by

Slot Access Functions

Inherited Slot Access Functions

See also

2024-6-27