The user interface is then built by adding buttons, drop-down menus, input
fields, and other widgets to the window. If you are creating complex user
interfaces it is recommended to use GtkBuilder and its GTK-specific markup
-description language, instead of assembling the interface manually. You can
-also use a visual user interface editor, like [Glade](https://glade.gnome.org/).
+description language, instead of assembling the interface manually.
GTK is event-driven. The toolkit listens for events such as a click
on a button, and passes the event to your application.
`/usr/share/appname`.
It is also possible to embed the UI description in the source code as a
-string and use [`method@Gtk.Builder.add_from_string`] to load it. But keeping the
-UI description in a separate file has several advantages: It is then possible
-to make minor adjustments to the UI without recompiling your program, and,
-more importantly, graphical UI editors such as [Glade](http://glade.gnome.org)
-can load the file and allow you to create and modify your UI by point-and-click.
+string and use [`method@Gtk.Builder.add_from_string`] to load it. But keeping
+the UI description in a separate file has several advantages:
+
+- it is possible to make minor adjustments to the UI without recompiling your
+ program
+- it is easier to isolate the UI code from the business logic of your
+ application
+- it is easier to restructure your UI into separate classes using composite
+ widget templates
+
+Using [GResource](https://docs.gtk.org/gio/struct.Resource.html) it is possible
+to combine the best of both worlds: you can keep the UI definition files
+separate inside your source code repository, and then ship them embedded into
+your application.
## Building applications
* The interface description semantics expected in composite template descriptions
* is slightly different from regular [class@Gtk.Builder] XML.
*
- * Unlike regular interface descriptions, [method@Gtk.WidgetClass.set_template] 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 `GtkBuilder` but required for UI design tools like
- * [Glade](https://glade.gnome.org/) to introspect what kind of properties and
- * internal children exist for a given type when the actual type does not exist.
+ * Unlike regular interface descriptions, [method@Gtk.WidgetClass.set_template]
+ * 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 `GtkBuilder` but can be used by UI design tools 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 the widget itself. You may set properties