Commit 7f6a964c authored by Matthias Clasen's avatar Matthias Clasen

Docs: Remove all entities and turn off sgml mode

With all element markup gone, it is time to turn off
sgml mode, and get rid of entities as well.
parent ab0574a8
......@@ -48,7 +48,7 @@ AM_CPPFLAGS = \
GTKDOC_LIBS = $(top_builddir)/gdk/libgdk-3.la $(GDK_DEP_LIBS)
# Extra options to supply to gtkdoc-mkdb
MKDB_OPTIONS=--sgml-mode --output-format=xml --name-space=gdk
MKDB_OPTIONS=--output-format=xml --name-space=gdk
# Extra SGML files that are included by DOC_MAIN_SGML_FILE
content_files = \
......
......@@ -126,7 +126,7 @@ GTKDOC_LIBS = \
# Extra options to supply to gtkdoc-mkdb
MKDB_OPTIONS=--sgml-mode --output-format=xml --name-space=gtk
MKDB_OPTIONS=--output-format=xml --name-space=gtk
# Extra SGML files that are included by $(DOC_MAIN_SGML_FILE)
content_files = \
......
......@@ -131,13 +131,12 @@ G_DEFINE_BOXED_TYPE (GdkColor, gdk_color,
* @red, @green, and @blue fields of a #GdkColor.
*
* The string can either one of a large set of standard names
* (taken from the X11 `rgb.txt` file), or
* it can be a hex value in the form “#rgb” “#rrggbb”
* “#rrrgggbbb” or “#rrrrggggbbbb” where “r”, “g” and
* “b” are hex digits of the red, green, and blue components
* of the color, respectively. (White in the four forms is
* “#fff”, “#ffffff”, “#fffffffff” and
* “#ffffffffffff”).
* (taken from the X11 `rgb.txt` file), or it can be a hexadecimal
* value in the form “\#rgb” “\#rrggbb”, “\#rrrgggbbb” or
* “\#rrrrggggbbbb” where “r”, “g” and “b” are hex digits of
* the red, green, and blue components of the color, respectively.
* (White in the four forms is “\#fff”, “\#ffffff”, “\#fffffffff”
* and “\#ffffffffffff”).
*
* Return value: %TRUE if the parsing succeeded
*/
......@@ -163,9 +162,8 @@ gdk_color_parse (const gchar *spec,
* gdk_color_to_string:
* @color: a #GdkColor
*
* Returns a textual specification of @color in the hexadecimal form
* `#rrrrggggbbbb`, where `r`,
* `g` and `b` are hex digits
* Returns a textual specification of @color in the hexadecimal
* form `\#rrrrggggbbbb`, where `r`, `g` and `b` are hex digits
* representing the red, green and blue components respectively.
*
* The returned string can be parsed by gdk_color_parse().
......
......@@ -1084,11 +1084,11 @@ gdk_device_get_n_axes (GdkDevice *device)
* gdk_device_list_axes:
* @device: a pointer #GdkDevice
*
* Returns a #GList of #GdkAtom<!-- -->s, containing the labels for
* Returns a #GList of #GdkAtoms, containing the labels for
* the axes that @device currently has.
*
* Returns: (transfer container) (element-type GdkAtom):
* A #GList of #GdkAtom<!-- -->s, free with g_list_free().
* A #GList of #GdkAtoms, free with g_list_free().
*
* Since: 3.0
**/
......
......@@ -307,7 +307,7 @@ gdk_device_manager_get_display (GdkDeviceManager *device_manager)
* @device_manager.
*
* Returns: (transfer container) (element-type Gdk.Device): a list of
* #GdkDevice<!-- -->s. The returned list must be
* #GdkDevices. The returned list must be
* freed with g_list_free (). The list elements are owned by
* GTK+ and must not be freed or unreffed.
*
......
......@@ -2110,12 +2110,12 @@ static GQueue gdk_error_traps = G_QUEUE_INIT;
* ## Trapping an X error
*
* |[<!-- language="C" -->
* gdk_error_trap_push (<!-- -->);
* gdk_error_trap_push ();
*
* // ... Call the X function which may cause an error here ...
*
*
* if (gdk_error_trap_pop (<!-- -->))
* if (gdk_error_trap_pop ())
* {
* // ... Handle the error here ...
* }
......
......@@ -495,12 +495,10 @@ gdk_keymap_lookup_key (GdkKeymap *keymap,
* @state. For convenience, #GdkEventKey already contains the translated
* keyval, so this function isn’t as useful as you might think.
*
* @consumed_modifiers gives modifiers that should be masked out
* from @state when comparing this key press to a hot key. For
* instance, on a US keyboard, the `plus`
* symbol is shifted, so when comparing a key press to a
* `&lt;Control&gt;plus` accelerator &lt;Shift&gt; should
* be masked out.
* @consumed_modifiers gives modifiers that should be masked outfrom @state
* when comparing this key press to a hot key. For instance, on a US keyboard,
* the `plus` symbol is shifted, so when comparing a key press to a
* `<Control>plus` accelerator `<Shift>` should be masked out.
*
* |[<!-- language="C" -->
* /&ast; We want to ignore irrelevant modifiers like ScrollLock &ast;/;
......@@ -525,16 +523,14 @@ gdk_keymap_lookup_key (GdkKeymap *keymap,
* ]|
*
* However, this did not work if multi-modifier combinations were
* used in the keymap, since, for instance, `&lt;Control&gt;`
* would be masked out even if only `&lt;Control&gt;&lt;Alt&gt;`
* was used in the keymap. To support this usage as well as well as
* possible, all single modifier combinations
* that could affect the key for any combination of modifiers will
* be returned in @consumed_modifiers; multi-modifier combinations
* are returned only when actually found in @state. When you store
* accelerators, you should always store them with consumed modifiers
* removed. Store `&lt;Control&gt;plus`,
* not `&lt;Control&gt;&lt;Shift&gt;plus`,
* used in the keymap, since, for instance, `<Control>` would be
* masked out even if only `<Control><Alt>` was used in the keymap.
* To support this usage as well as well as possible, all single
* modifier combinations that could affect the key for any combination
* of modifiers will be returned in @consumed_modifiers; multi-modifier
* combinations are returned only when actually found in @state. When
* you store accelerators, you should always store them with consumed
* modifiers removed. Store `<Control>plus`, not `<Control><Shift>plus`,
*
* Return value: %TRUE if there was a keyval bound to the keycode/state/group
**/
......
......@@ -142,8 +142,8 @@ parse_rgb_value (const gchar *str,
*
* The string can be either one of:
* - A standard name (Taken from the X11 rgb.txt file).
* - A hex value in the form “&num;rgb” “&num;rrggbb” “&num;rrrgggbbb”
* or “&num;rrrrggggbbbb”
* - A hexadecimal value in the form “\#rgb”, “\#rrggbb”,
* “\#rrrgggbbb” or ”\#rrrrggggbbbb”
* - A RGB color in the form “rgb(r,g,b)” (In this case the color will
* have full opacity)
* - A RGBA color in the form “rgba(r,g,b,a)”
......
......@@ -1020,7 +1020,7 @@ gdk_screen_get_active_window (GdkScreen *screen)
* gdk_screen_get_window_stack:
* @screen: a #GdkScreen
*
* Returns a #GList of #GdkWindow<!-- -->s representing the current
* Returns a #GList of #GdkWindows representing the current
* window stack.
*
* On X11, this is done by inspecting the _NET_CLIENT_LIST_STACKING
......@@ -1037,7 +1037,7 @@ gdk_screen_get_active_window (GdkScreen *screen)
* its windows unrefed using g_object_unref() when no longer needed.
*
* Return value: (transfer full) (element-type GdkWindow):
* a list of #GdkWindow<!-- -->s for the current window stack,
* a list of #GdkWindows for the current window stack,
* or %NULL.
*
* Since: 2.10
......
......@@ -40,10 +40,9 @@
* @Title: Wayland Interaction
*
* The functions in this section are specific to the GDK Wayland backend.
* To use them, you need to include the `&lt;gdk/gdkwayland.h&gt;`
* header and use the Wayland-specific pkg-config files to build your
* application (either `gdk-wayland-3.0` or
* `gtk+-wayland-3.0`).
* To use them, you need to include the `<gdk/gdkwayland.h>` header and use
* the Wayland-specific pkg-config files to build your application (either
* `gdk-wayland-3.0` or `gtk+-wayland-3.0`).
*
* To make your code compile with other GDK backends, guard backend-specific
* calls by an ifdef as follows. Since GDK may be built with multiple
......
......@@ -52,10 +52,9 @@
* @Title: X Window System Interaction
*
* The functions in this section are specific to the GDK X11 backend.
* To use them, you need to include the `&lt;gdk/gdkx.h&gt;`
* header and use the X11-specific pkg-config files to build your
* application (either `gdk-x11-3.0` or
* `gtk+-x11-3.0`).
* To use them, you need to include the `<gdk/gdkx.h>` header and use
* the X11-specific pkg-config files to build your application (either
* `gdk-x11-3.0` or `gtk+-x11-3.0`).
*
* To make your code compile with other GDK backends, guard backend-specific
* calls by an ifdef as follows. Since GDK may be built with multiple
......
......@@ -48,24 +48,23 @@
*
* Accelerators are handled by the GTK+ accelerator map. All actions are
* assigned an accelerator path (which normally has the form
* `&lt;Actions&gt;/group-name/action-name`)
* and a shortcut is associated with this accelerator path. All menuitems
* and toolitems take on this accelerator path. The GTK+ accelerator map
* code makes sure that the correct shortcut is displayed next to the menu
* item.
* `<Actions>/group-name/action-name`) and a shortcut is associated with
* this accelerator path. All menuitems and toolitems take on this accelerator
* path. The GTK+ accelerator map code makes sure that the correct shortcut
* is displayed next to the menu item.
*
* # GtkActionGroup as GtkBuildable # {#GtkActionGroup-BUILDER-UI}
*
* The #GtkActionGroup implementation of the #GtkBuildable interface accepts
* #GtkAction objects as &lt;child&gt; elements in UI definitions.
* #GtkAction objects as <child> elements in UI definitions.
*
* Note that it is probably more common to define actions and action groups
* in the code, since they are directly related to what the code can do.
*
* The GtkActionGroup implementation of the GtkBuildable interface supports
* a custom &lt;accelerator&gt; element, which has attributes named key and
* modifiers and allows to specify accelerators. This is similar to the
* &lt;accelerator&gt; element of #GtkWidget, the main difference is that
* a custom <accelerator> element, which has attributes named “key“ and
* “modifiers“ and allows to specify accelerators. This is similar to the
* <accelerator> element of #GtkWidget, the main difference is that
* it doesn’t allow you to specify a signal.
*
* ## A #GtkDialog UI definition fragment. ##
......@@ -964,8 +963,7 @@ gtk_action_group_add_action (GtkActionGroup *action_group,
* If @accelerator is %NULL, attempts to use the accelerator associated
* with the stock_id of the action.
*
* Accel paths are set to
* `&lt;Actions&gt;/group-name/action-name`.
* Accel paths are set to `<Actions>/group-name/action-name`.
*
* Since: 2.4
*
......@@ -1108,9 +1106,8 @@ gtk_action_group_list_actions (GtkActionGroup *action_group)
* This is a convenience function to create a number of actions and add them
* to the action group.
*
* The “activate” signals of the actions are connected to the callbacks and
* their accel paths are set to
* `&lt;Actions&gt;/group-name/action-name`.
* The “activate” signals of the actions are connected to the callbacks
* and their accel paths are set to `<Actions>/group-name/action-name`.
*
* Since: 2.4
*
......@@ -1243,9 +1240,8 @@ gtk_action_group_add_actions_full (GtkActionGroup *action_group,
* This is a convenience function to create a number of toggle actions and add them
* to the action group.
*
* The “activate” signals of the actions are connected to the callbacks and
* their accel paths are set to
* `&lt;Actions&gt;/group-name/action-name`.
* The “activate” signals of the actions are connected to the callbacks
* and their accel paths are set to `<Actions>/group-name/action-name`.
*
* Since: 2.4
*
......@@ -1365,7 +1361,7 @@ gtk_action_group_add_toggle_actions_full (GtkActionGroup *action_gro
*
* The “changed” signal of the first radio action is connected to the
* @on_change callback and the accel paths of the actions are set to
* `&lt;Actions&gt;/group-name/action-name`.
* `<Actions>/group-name/action-name`.
*
* Since: 2.4
*
......
......@@ -72,9 +72,8 @@
*
* # GtkIconFactory as GtkBuildable # {#GtkIconFactory-BUILDER-UI}
*
* GtkIconFactory supports a custom &lt;sources&gt; element, which can contain
* multiple &lt;source&gt; elements.
* The following attributes are allowed:
* GtkIconFactory supports a custom <sources> element, which can contain
* multiple <source> elements. The following attributes are allowed:
*
* - stock-id
*
......
......@@ -134,18 +134,18 @@
* the class name of the widget, while for the class path, the class name is
* always used.
*
* Since GTK+ 2.10, `widget_class` paths can also contain
* `&lt;classname&gt;` substrings, which are matching
* the class with the given name and any derived classes. For instance,
* Since GTK+ 2.10, `widget_class` paths can also contain <classname>
* substrings, which are matching the class with the given name and any
* derived classes. For instance,
* |[
* widget_class "*&lt;GtkMenuItem&gt;.GtkLabel" style "my-style"
* widget_class "*<GtkMenuItem>.GtkLabel" style "my-style"
* ]|
* will match #GtkLabel widgets which are contained in any kind of menu item.
*
* So, if you have a #GtkEntry named `"myentry"`, inside of a
* horizontal box in a window named `"mywindow"`, then the
* widget path is: `"mywindow.GtkHBox.myentry"`
* while the class path is: `"GtkWindow.GtkHBox.GtkEntry"`.
* So, if you have a #GtkEntry named `"myentry"`, inside of a horizontal
* box in a window named `"mywindow"`, then the widget path is:
* `"mywindow.GtkHBox.myentry"` while the class path is:
* `"GtkWindow.GtkHBox.GtkEntry"`.
*
* Matching against class is a little different. The pattern match is done
* against all class names in the widgets class hierarchy (not the layout
......@@ -372,12 +372,11 @@
* * `bg_pixmap[state] =
* pixmap`
*
* Sets a background pixmap to be used in place of
* the `bg` color (or for #GtkText,
* in place of the `base` color. The special
* value `"&lt;parent&gt;"` may be used to indicate that the widget should
* Sets a background pixmap to be used in place of the `bg` color
* (or for #GtkText, in place of the `base` color. The special
* value `"<parent>"` may be used to indicate that the widget should
* use the same background pixmap as its parent. The special value
* `"&lt;none&gt;"` may be used to indicate no background pixmap.
* `"<none>"` may be used to indicate no background pixmap.
* * `font = font`
*
......@@ -578,54 +577,46 @@
* }
* ]|
*
* `key` is a string consisting of a
* series of modifiers followed by the name of a key. The
* modifiers can be:
* `key` is a string consisting of a series of modifiers followed by
* the name of a key. The modifiers can be:
*
* - `&lt;alt&gt;`
* - `<alt>`
*
* - `&lt;ctl&gt;`
* - `<ctl>`
*
* - `&lt;control&gt;`
* - `<control>`
*
* - `&lt;meta&gt;`
* - `<meta>`
*
* - `&lt;hyper&gt;`
* - `<hyper>`
*
* - `&lt;super&gt;`
* - `<super>`
*
* - `&lt;mod1&gt;`
* - `<mod1>`
*
* - `&lt;mod2&gt;`
* - `<mod2>`
*
* - `&lt;mod3&gt;`
* - `<mod3>`
*
* - `&lt;mod4&gt;`
* - `<mod4>`
*
* - `&lt;mod5&gt;`
* - `<mod5>`
*
* - `&lt;release&gt;`
* - `<release>`
*
* - `&lt;shft&gt;`
* - `<shft>`
*
* - `&lt;shift&gt;`
* - `<shift>`
*
* `&lt;shft&gt;` is an alias for
* `&lt;shift&gt;`,
* `&lt;ctl&gt;` is an alias for
* `&lt;control&gt;`,
* and
* `&lt;alt&gt;` is an alias for
* `&lt;mod1&gt;`.
* `<shft>` is an alias for `<shift>`, `<ctl>` is an alias for
* `<control>`, and `<alt>` is an alias for `<mod1>`.
*
* The action that is bound to the key is a sequence
* of signal names (strings) followed by parameters for
* each signal. The signals must be action signals.
* (See g_signal_new()). Each parameter can be
* a float, integer, string, or unquoted string
* representing an enumeration value. The types of
* the parameters specified must match the types of the
* parameters of the signal.
* The action that is bound to the key is a sequence of signal names
* (strings) followed by parameters for each signal. The signals must
* be action signals. (See g_signal_new()). Each parameter can be a
* float, integer, string, or unquoted string representing an enumeration
* value. The types of the parameters specified must match the types of
* the parameters of the signal.
*
* Binding sets are connected to widgets in the same manner as styles,
* with one difference: Binding sets override other binding sets first
......
......@@ -41,9 +41,9 @@
* #GtkRecentChooserMenu.
*
* To construct a submenu showing recently used files, use a #GtkRecentAction
* as the action for a &lt;menuitem&gt;. To construct a menu toolbutton showing
* as the action for a <menuitem>. To construct a menu toolbutton showing
* the recently used files in the popup menu, use a #GtkRecentAction as the
* action for a &lt;toolitem&gt; element.
* action for a <toolitem> element.
*/
......
......@@ -205,10 +205,10 @@
*
* # Accelerators #
*
* Every action has an accelerator path. Accelerators are installed together with
* menuitem proxies, but they can also be explicitly added with &lt;accelerator&gt;
* elements in the UI definition. This makes it possible to have accelerators for
* actions even if they have no visible proxies.
* Every action has an accelerator path. Accelerators are installed together
* with menuitem proxies, but they can also be explicitly added with
* <accelerator> elements in the UI definition. This makes it possible to
* have accelerators for actions even if they have no visible proxies.
*
* # Smart Separators # {#Smart-Separators}
*
......@@ -240,10 +240,10 @@
* # GtkUIManager as GtkBuildable # {#GtkUIManager-BUILDER-UI}
*
* The GtkUIManager implementation of the GtkBuildable interface accepts
* GtkActionGroup objects as &lt;child&gt; elements in UI definitions.
* GtkActionGroup objects as <child> elements in UI definitions.
*
* A GtkUIManager UI definition as described above can be embedded in
* an GtkUIManager &lt;object&gt; element in a GtkBuilder UI definition.
* an GtkUIManager <object> element in a GtkBuilder UI definition.
*
* The widgets that are constructed by a GtkUIManager can be embedded in
* other parts of the constructed user interface with the help of the
......@@ -1093,19 +1093,20 @@ gtk_ui_manager_get_accel_group (GtkUIManager *manager)
* Looks up a widget by following a path.
* The path consists of the names specified in the XML description of the UI.
* separated by “/”. Elements which don’t have a name or action attribute in
* the XML (e.g. &lt;popup&gt;) can be addressed by their XML element name
* the XML (e.g. <popup>) can be addressed by their XML element name
* (e.g. "popup"). The root element ("/ui") can be omitted in the path.
*
* Note that the widget found by following a path that ends in a &lt;menu&gt;
* element is the menuitem to which the menu is attached, not the menu itmanager.
* Note that the widget found by following a path that ends in a <menu>;
* element is the menuitem to which the menu is attached, not the menu it
* manages.
*
* Also note that the widgets constructed by a ui manager are not tied to
* the lifecycle of the ui manager. If you add the widgets returned by this
* function to some container or explicitly ref them, they will survive the
* destruction of the ui manager.
*
* Return value: (transfer none): the widget found by following the path, or %NULL if no widget
* was found.
* Return value: (transfer none): the widget found by following the path,
* or %NULL if no widget was found
*
* Since: 2.4
*
......@@ -1932,9 +1933,9 @@ add_ui_from_string (GtkUIManager *manager,
* @length: the length of @buffer (may be -1 if @buffer is nul-terminated)
* @error: return location for an error
*
* Parses a string containing a [UI definition][XML-UI] and
* merges it with the current contents of @manager. An enclosing &lt;ui&gt;
* element is added if it is missing.
* Parses a string containing a [UI definition][XML-UI] and merges it with
* the current contents of @manager. An enclosing <ui> element is added if
* it is missing.
*
* Return value: The merge id for the merged UI. The merge id can be used
* to unmerge the UI with gtk_ui_manager_remove_ui(). If an error occurred,
......
......@@ -79,11 +79,11 @@
* use the function gtk_show_about_dialog() which constructs and shows a dialog
* and keeps it around so that it can be shown again.
*
* Note that GTK+ sets a default title of `_("About &percnt;s")`
* on the dialog window (where &percnt;s is replaced by the name of the
* application, but in order to ensure proper translation of the title,
* applications should set the title property explicitly when constructing
* a GtkAboutDialog, as shown in the following example:
* Note that GTK+ sets a default title of `_("About \%s")` on the dialog
* window (where \%s is replaced by the name of the application, but in
* order to ensure proper translation of the title, applications should
* set the title property explicitly when constructing a GtkAboutDialog,
* as shown in the following example:
* |[<!-- language="C" -->
* gtk_show_about_dialog (NULL,
* "program-name", "ExampleCode",
......
......@@ -1441,15 +1441,15 @@ out:
* @accelerator_mods: (out) (allow-none): return location for accelerator
* modifier mask, %NULL
*
* Parses a string representing an accelerator. The
* format looks like “&lt;Control&gt;a” or “&lt;Shift&gt;&lt;Alt&gt;F1”
* or “&lt;Release&gt;z” (the last one is for key release).
* Parses a string representing an accelerator. The format looks like
* “<Control>a” or “<Shift><Alt>F1” or “<Release>z” (the last one is
* for key release).
*
* The parser is fairly liberal and allows lower or upper case,
* and also abbreviations such as “&lt;Ctl&gt;” and “&lt;Ctrl&gt;”.
* Key names are parsed using gdk_keyval_from_name(). For character
* keys the name is not the symbol, but the lowercase name, e.g. one
* would use “&lt;Ctrl&gt;minus” instead of “&lt;Ctrl&gt;-”.
* The parser is fairly liberal and allows lower or upper case, and also
* abbreviations such as “<Ctl>” and “<Ctrl>”. Key names are parsed using
* gdk_keyval_from_name(). For character keys the name is not the symbol,
* but the lowercase name, e.g. one would use “<Ctrl>minus” instead of
* “<Ctrl>-”.
*
* If the parse fails, @accelerator_key and @accelerator_mods will
* be set to 0 (zero).
......@@ -1509,10 +1509,9 @@ gtk_accelerator_name_with_keycode (GdkDisplay *display,
* @accelerator_key: accelerator keyval
* @accelerator_mods: accelerator modifier mask
*
* Converts an accelerator keyval and modifier mask
* into a string parseable by gtk_accelerator_parse().
* For example, if you pass in #GDK_KEY_q and #GDK_CONTROL_MASK,
* this function returns “&lt;Control&gt;q”.
* Converts an accelerator keyval and modifier mask into a string
* parseable by gtk_accelerator_parse(). For example, if you pass in
* #GDK_KEY_q and #GDK_CONTROL_MASK, this function returns “<Control>q”.
*
* If you need to display accelerators in the user interface,
* see gtk_accelerator_get_label().
......
......@@ -72,19 +72,21 @@
* GtkWidget *save_item;
* GtkAccelGroup *accel_group;
*
* /<!---->* Create a GtkAccelGroup and add it to the window. *<!---->/
* accel_group = gtk_accel_group_new (<!-- -->);
* /&ast; Create a GtkAccelGroup and add it to the window. &ast;/
* accel_group = gtk_accel_group_new ();
* gtk_window_add_accel_group (GTK_WINDOW (window), accel_group);
*
* /<!---->* Create the menu item using the convenience function. *<!---->/
* /&ast; Create the menu item using the convenience function. &ast;/
* save_item = gtk_menu_item_new_with_label ("Save");
* gtk_widget_show (save_item);
* gtk_container_add (GTK_CONTAINER (menu), save_item);
*
* /<!---->* Now add the accelerator to the GtkMenuItem. Note that since we called
* gtk_menu_item_new_with_label(<!-- -->) to create the GtkMenuItem the
* GtkAccelLabel is automatically set up to display the GtkMenuItem
* accelerators. We just need to make sure we use GTK_ACCEL_VISIBLE here. *<!---->/
* /&ast; Now add the accelerator to the GtkMenuItem. Note that since we
* &ast; called gtk_menu_item_new_with_label() to create the GtkMenuItem
* &ast; the GtkAccelLabel is automatically set up to display the
* &ast; GtkMenuItem accelerators. We just need to make sure we use
* &ast; GTK_ACCEL_VISIBLE here.
* &ast;/
* gtk_widget_add_accelerator (save_item, "activate", accel_group,
* GDK_KEY_s, GDK_CONTROL_MASK, GTK_ACCEL_VISIBLE);
* ]|
......
......@@ -54,7 +54,7 @@
* - accelerator modifiers
*
* The accelerator path must consist of
* “&lt;WINDOWTYPE&gt;/Category1/Category2/.../Action”, where WINDOWTYPE
* “<WINDOWTYPE>/Category1/Category2/.../Action”, where WINDOWTYPE
* should be a unique application-specific identifier that corresponds
* to the kind of window the accelerator is being used in, e.g.
* “Gimp-Image”, “Abiword-Document” or “Gnumeric-Settings”.
......@@ -62,7 +62,7 @@
* the action the accelerator triggers, i.e. for accelerators on menu
* items, choose the item’s menu path, e.g. “File/Save As”,
* “Image/View/Zoom” or “Edit/Select All”. So a full valid accelerator
* path may look like: “&lt;Gimp-Toolbox&gt;/File/Dialogs/Tool Options...”.
* path may look like: “<Gimp-Toolbox>/File/Dialogs/Tool Options...”.
*
* All accelerators are stored inside one global #GtkAccelMap that can
* be obtained using gtk_accel_map_get(). See
......
......@@ -1073,9 +1073,8 @@ gtk_application_update_accels (GtkApplication *application)
* to be activated when the key combination specificed by @accelerator
* is pressed.
*
* @accelerator must be a string that can be parsed by
* gtk_accelerator_parse(), e.g. "&lt;Primary&gt;q" or
* “&lt;Control&gt;&lt;Alt&gt;p”.
* @accelerator must be a string that can be parsed by gtk_accelerator_parse(),
* e.g. "<Primary>q" or “<Control><Alt>p”.
*
* @action_name must be the name of an action as it would be used
* in the app menu, i.e. actions that have been added to the application
......
......@@ -107,20 +107,17 @@
* [A simple example](https://git.gnome.org/browse/gtk+/tree/examples/sunny.c)
*
* The XML format understood by #GtkBuilder for #GMenuModel consists
* of a toplevel `&lt;menu&gt;` element, which contains
* one or more `&lt;item&gt;` elements. Each
* `&lt;item&gt;` element contains
* `&lt;attribute&gt;` and `&lt;link&gt;`
* elements with a mandatory name attribute.
* `&lt;link&gt;` elements have the same content
* model as `&lt;menu&gt;`.
* of a toplevel `<menu>` element, which contains one or more `<item>`
* elements. Each `<item>` element contains `<attribute>` and `<link>`
* elements with a mandatory name attribute. `<link>` elements have the
* same content model as `<menu>`.
*
* Attribute values can be translated using gettext, like other #GtkBuilder
* content. `&lt;attribute&gt;` elements can be marked for
* translation with a `translatable="yes"` attribute.
* It is also possible to specify message context and translator comments,
* using the context and comments attributes. To make use of this, the
* #GtkBuilder must have been given the gettext domain to use.
* content. `<attribute>` elements can be marked for translation with a
* `translatable="yes"` attribute. It is also possible to specify message
* context and translator comments,using the context and comments attributes.
* To make use of this, the #GtkBuilder must have been given the gettext
* domain to use.
*/
typedef GSimpleActionGroupClass GtkApplicationWindowActionsClass;
......
......@@ -104,15 +104,15 @@
* ]|
*
* The above example will not have the desired effect of causing
* “&lt;Control&gt;Right” and “&lt;Control&gt;Left” key presses to
* be ignored by GTK+. Instead, it just causes any existing bindings
* from the bindings set “MoveCursor3” to be deleted, so when
* “&lt;Control&gt;Right” or “&lt;Control&gt;Left” are pressed, no
* binding for these keys is found in binding set “MoveCursor3”.
* GTK+ will thus continue to search for matching key bindings, and
* will eventually lookup and find the default GTK+ bindings for
* entries which implement word movement. To keep GTK+ from activating
* its default bindings, the “unbind” keyword can be used like this:
* “<Control>Right” and “<Control>Left” key presses to be ignored by GTK+.
* Instead, it just causes any existing bindings from the bindings set
* “MoveCursor3” to be deleted, so when “<Control>Right” or
* “<Control>Left” are pressed, no binding for these keys is found in
* binding set “MoveCursor3”. GTK+ will thus continue to search for
* matching key bindings, and will eventually lookup and find the default
* GTK+ bindings for entries which implement word movement. To keep GTK+
* from activating its default bindings, the “unbind” keyword can be used
* like this:
*
* |[
* @binding-set MoveCursor3
......@@ -126,12 +126,11 @@
* }
* ]|
*
* Now, GTK+ will find a match when looking up “&lt;Control&gt;Right”
* and “&lt;Control&gt;Left” key presses before it resorts to its default
* bindings, and the match instructs it to abort (“unbind”) the search,
* so the key presses are not consumed by this widget. As usual, further
* processing of the key presses, e.g. by an entry’s parent widget, is
* now possible.
* Now, GTK+ will find a match when looking up “<Control>Right” and
* “<Control>Left” key presses before it resorts to its default bindings,
* and the match instructs it to abort (“unbind”) the search, so the key
* presses are not consumed by this widget. As usual, further processing
* of the key presses, e.g. by an entry’s parent widget, is now possible.
*/
/* --- defines --- */
......
......@@ -236,7 +236,7 @@ gtk_buildable_construct_child (GtkBuildable *buildable,
* @data: (out): return location for user data that will be passed in
* to parser functions
*
* This is called for each unknown element under &lt;child&gt;.
* This is called for each unknown element under <child>.
*
* Returns: %TRUE if a object has a custom implementation, %FALSE
* if it doesn't.
......
......@@ -71,33 +71,32 @@
*
* [RELAX NG Compact Syntax](https://git.gnome.org/browse/gtk+/tree/gtk/gtkbuilder.rnc)
*
* The toplevel element is &lt;interface&gt;. 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 &lt;object&gt; elements, which can contain
* &lt;property&gt; elements to set properties, &lt;signal&gt; elements
* which connect signals to handlers, and &lt;child&gt; 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 &lt;child&gt; element contains an &lt;object&gt; element which
* describes the child object. The target toolkit version(s) are
* described by &lt;requires&gt; elements, the “lib” attribute specifies
* the widget library in question (currently the only supported value
* s “gtk+”) and the “version” attribute specifies the target version
* in the form “&lt;major&gt;.&lt;minor&gt;”. The builder will error
* The toplevel element is <interface>. 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 <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 e.g.
* 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 &lt;object&gt;
* 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.
* 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() function from the