diff --git a/docs/reference/gtk/getting_started.md b/docs/reference/gtk/getting_started.md
index 661b8b466f..bde0a6d0d0 100644
--- a/docs/reference/gtk/getting_started.md
+++ b/docs/reference/gtk/getting_started.md
@@ -8,8 +8,7 @@ are organized in a hierarchy. The window widget is the main container.
 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.
@@ -712,11 +711,20 @@ A common location to install UI descriptions and similar data is
 `/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
 
diff --git a/gtk/gtkwidget.c b/gtk/gtkwidget.c
index b57d8c340c..47aa0b5c5c 100644
--- a/gtk/gtkwidget.c
+++ b/gtk/gtkwidget.c
@@ -321,14 +321,14 @@
  * 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