Commit 09d1b282 authored by Matthias Clasen's avatar Matthias Clasen

docs: Convert to markdown

Specifically, switch to using markdown syntax for sections.
parent 16e38946
......@@ -56,40 +56,36 @@
* A #GdkWindow is a (usually) rectangular region on the screen.
* It's a low-level object, used to implement high-level objects such as
* #GtkWidget and #GtkWindow on the GTK+ level. A #GtkWindow is a toplevel
* window, the thing a user might think of as a "window" with a titlebar and
* so on; a #GtkWindow may contain many #GdkWindows. For example, each
* #GtkButton has a #GdkWindow associated with it.
*
* <refsect2 id="COMPOSITED-WINDOWS">
* <title>Composited Windows</title>
* <para>
* Normally, the windowing system takes care of rendering the contents of a
* child window onto its parent window. This mechanism can be intercepted by
* calling gdk_window_set_composited() on the child window. For a
* <firstterm>composited</firstterm> window it is the responsibility of the
* application to render the window contents at the right spot.
* </para>
* </refsect2>
* <refsect2 id="OFFSCREEN-WINDOWS">
* <title>Offscreen Windows</title>
* <para>
* Offscreen windows are more general than composited windows, since they allow
* not only to modify the rendering of the child window onto its parent, but
* also to apply coordinate transformations.
*
* To integrate an offscreen window into a window hierarchy, one has to call
* gdk_offscreen_window_set_embedder() and handle a number of signals. The
* #GdkWindow::pick-embedded-child signal on the embedder window is used to
* select an offscreen child at given coordinates, and the
* #GdkWindow::to-embedder and #GdkWindow::from-embedder signals on the
* offscreen window are used to translate coordinates between the embedder and
* the offscreen window.
*
* For rendering an offscreen window onto its embedder, the contents of the
* offscreen window are available as a surface, via
* window, the thing a user might think of as a "window" with a titlebar
* and so on; a #GtkWindow may contain many #GdkWindows. For example,
* each #GtkButton has a #GdkWindow associated with it.
*
* ## Composited Windows
*
* <para id="COMPOSITED-WINDOWS">Normally, the windowing system takes care of rendering the contents
* of a child window onto its parent window. This mechanism can be
* intercepted by calling gdk_window_set_composited() on the child
* window. For a <firstterm>composited</firstterm> window it is the
* responsibility of the application to render the window contents at
* the right spot.</para>
*
* ## Offscreen Windows
*
* <para id="OFFSCREEN-WINDOWS">Offscreen windows are more general than composited windows, since
* they allow not only to modify the rendering of the child window onto
* its parent, but also to apply coordinate transformations.</para>
*
* To integrate an offscreen window into a window hierarchy, one has
* to call gdk_offscreen_window_set_embedder() and handle a number of
* signals. The #GdkWindow::pick-embedded-child signal on the embedder
* window is used to select an offscreen child at given coordinates,
* and the #GdkWindow::to-embedder and #GdkWindow::from-embedder signals
* on the offscreen window are used to translate coordinates between
* the embedder and the offscreen window.
*
* For rendering an offscreen window onto its embedder, the contents
* of the offscreen window are available as a surface, via
* gdk_offscreen_window_get_surface().
* </para>
* </refsect2>
*/
......
......@@ -48,61 +48,53 @@
* "low-level". You'll want to use them if you're manually creating menus that
* should have user-configurable accelerators.
*
* Accelerator is uniquely defined by:
*
* <itemizedlist>
* <listitem><para>accelerator path</para></listitem>
* <listitem><para>accelerator key</para></listitem>
* <listitem><para>accelerator modifiers</para></listitem>
* </itemizedlist>
* An accelerator is uniquely defined by:
* - accelerator path
* - accelerator key
* - accelerator modifiers
*
* The accelerator path must consist of
* "&lt;WINDOWTYPE&gt;/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".
* The "Category1/.../Action" portion is most appropriately chosen by 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...".
* 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".
* The "Category1/.../Action" portion is most appropriately chosen by
* 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...".
*
* All accelerators are stored inside one global #GtkAccelMap that can be
* obtained using gtk_accel_map_get(). See <link
* All accelerators are stored inside one global #GtkAccelMap that can
* be obtained using gtk_accel_map_get(). See <link
* linkend="monitoring-changes">Monitoring changes</link> for additional
* details.
*
* <refsect2 id="manipulating-accelerators">
* <title>Manipulating accelerators</title>
* <para>
* New accelerators can be added using gtk_accel_map_add_entry(). To search for
* specific accelerator, use gtk_accel_map_lookup_entry(). Modifications of
* existing accelerators should be done using gtk_accel_map_change_entry().
* ## Manipulating accelerators
*
* New accelerators can be added using gtk_accel_map_add_entry().
* To search for specific accelerator, use gtk_accel_map_lookup_entry().
* Modifications of existing accelerators should be done using
* gtk_accel_map_change_entry().
*
* In order to avoid having some accelerators changed, they can be locked using
* gtk_accel_map_lock_path(). Unlocking is done using
* In order to avoid having some accelerators changed, they can be
* locked using gtk_accel_map_lock_path(). Unlocking is done using
* gtk_accel_map_unlock_path().
* </para>
* </refsect2>
* <refsect2 id="saving-and-loading">
* <title>Saving and loading accelerator maps</title>
* <para>
* Accelerator maps can be saved to and loaded from some external resource. For
* simple saving and loading from file, gtk_accel_map_save() and
* gtk_accel_map_load() are provided. Saving and loading can also be done by
* providing file descriptor to gtk_accel_map_save_fd() and
* gtk_accel_map_load_fd().
* </para>
* </refsect2>
* <refsect2 id="monitoring-changes">
* <title>Monitoring changes</title>
* <para>
* #GtkAccelMap object is only useful for monitoring changes of accelerators. By
* connecting to #GtkAccelMap::changed signal, one can monitor changes of all
* accelerators. It is also possible to monitor only single accelerator path by
* using it as a detail of the #GtkAccelMap::changed signal.
* </para>
* </refsect2>
*
* ## Saving and loading accelerator maps
*
* Accelerator maps can be saved to and loaded from some external
* resource. For simple saving and loading from file,
* gtk_accel_map_save() and gtk_accel_map_load() are provided.
* Saving and loading can also be done by providing file descriptor
* to gtk_accel_map_save_fd() and gtk_accel_map_load_fd().
*
* ## Monitoring changes
*
* #GtkAccelMap object is only useful for monitoring changes of
* accelerators. By connecting to #GtkAccelMap::changed signal, one
* can monitor changes of all accelerators. It is also possible to
* monitor only single accelerator path by using it as a detail of
* the #GtkAccelMap::changed signal.
*/
......
......@@ -27,31 +27,29 @@
* @Title: GtkAssistant
*
* A #GtkAssistant is a widget used to represent a generally complex
* operation splitted in several steps, guiding the user through its pages
* and controlling the page flow to collect the necessary data.
* operation splitted in several steps, guiding the user through its
* pages and controlling the page flow to collect the necessary data.
*
* The design of GtkAssistant is that it controls what buttons to show and
* to make sensitive, based on what it knows about the page sequence and
* the <link linkend="GtkAssistantPageType">type</link> of each page, in
* addition to state information like the page
* <link linkend="gtk-assistant-set-page-complete">completion</link> and
* <link linkend="gtk-assistant-commit">committed</link> status.
* The design of GtkAssistant is that it controls what buttons to show
* and to make sensitive, based on what it knows about the page sequence
* and the <link linkend="GtkAssistantPageType">type</link> of each page,
* in addition to state information like the page
* <link linkend="gtk-assistant-set-page-complete">completion</link>
* and <link linkend="gtk-assistant-commit">committed</link> status.
*
* If you have a case that doesn't quite fit in #GtkAssistants way of
* handling buttons, you can use the #GTK_ASSISTANT_PAGE_CUSTOM page type
* and handle buttons yourself.
* handling buttons, you can use the #GTK_ASSISTANT_PAGE_CUSTOM page
* type and handle buttons yourself.
*
* <refsect2 id="GtkAssistant-BUILDER-UI">
* <title>GtkAssistant as GtkBuildable</title>
* <para>
* The GtkAssistant implementation of the GtkBuildable interface exposes the
* @action_area as internal children with the name "action_area".
* ## GtkAssistant as GtkBuildable
*
* To add pages to an assistant in GtkBuilder, simply add it as a
* &lt;child&gt; to the GtkAssistant object, and set its child properties
* The GtkAssistant implementation of the #GtkBuildable interface
* exposes the @action_area as internal children with the name
* "action_area".
*
* To add pages to an assistant in #GtkBuilder, simply add it as a
* child to the GtkAssistant object, and set its child properties
* as necessary.
* </para>
* </refsect2>
*/
#include "config.h"
......
......@@ -47,27 +47,27 @@
* with high key binding configurability which requires no application
* or toolkit side changes.
*
* <refsect2 id="gtk-bindings-install">
* <title>Installing a key binding</title>
* <para>
* ## Installing a key binding
*
* A CSS file binding consists of a 'binding-set' definition and a match
* statement to apply the binding set to specific widget types. Details
* on the matching mechanism are described under
* <link linkend="gtkcssprovider-selectors">Selectors</link>
* in the #GtkCssProvider documentation. Inside the binding set definition,
* key combinations are bound to one or more specific signal emissions on
* the target widget. Key combinations are strings consisting of an optional
* #GdkModifierType name and <link linkend="gdk3-Keyboard-Handling">key names</link>
* in the #GtkCssProvider documentation. Inside the binding set
* definition, key combinations are bound to one or more specific
* signal emissions on the target widget. Key combinations are strings
* consisting of an optional #GdkModifierType name and
* <link linkend="gdk3-Keyboard-Handling">key names</link>
* such as those defined in <filename>&lt;gdk/gdkkeysyms.h&gt;</filename>
* or returned from gdk_keyval_name(), they have to be parsable by
* gtk_accelerator_parse(). Specifications of signal emissions consist
* of a string identifying the signal name, and a list of signal specific
* arguments in parenthesis.
* </para>
* <para>
*
* For example for binding Control and the left or right cursor keys
* of a #GtkEntry widget to the #GtkEntry::move-cursor signal (so movement
* occurs in 3-character steps), the following binding can be used:
* of a #GtkEntry widget to the #GtkEntry::move-cursor signal (so
* movement occurs in 3-character steps), the following binding can be
* used:
* |[
* @binding-set MoveCursor3
* {
......@@ -79,11 +79,9 @@
* gtk-key-bindings: MoveCursor3;
* }
* ]|
* </para>
* </refsect2>
* <refsect2 id="gtk-bindings-unbind">
* <title>Unbinding existing key bindings</title>
* <para>
*
* ## Unbinding existing key bindings
*
* GTK+ already defines a number of useful bindings for the widgets
* it provides. Because custom bindings set up in CSS files take
* precedence over the default bindings shipped with GTK+, overriding
......@@ -108,10 +106,10 @@
* 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:
* 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
* {
......@@ -129,8 +127,6 @@
* 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.
* </para>
* </refsect2>
*/
/* --- defines --- */
......
This diff is collapsed.
......@@ -35,9 +35,8 @@
* Usually users dont have to interact with the #GtkCellArea directly
* unless they are implementing a cell-layouting widget themselves.
*
* <refsect2 id="cell-area-geometry-management">
* <title>Requesting area sizes</title>
* <para>
* ## Requesting area sizes
*
* As outlined in <link linkend="geometry-management">GtkWidget's
* geometry management section</link>, GTK+ uses a height-for-width
* geometry management system to compute the sizes of widgets and user
......@@ -72,9 +71,7 @@
*
* In order to request the width of all the rows at the root level
* of a #GtkTreeModel one would do the following:
* <example>
* <title>Requesting the width of a handful of GtkTreeModel rows</title>
* |[<!-- language="C" -->
* |[<!-- language="C" -->
* GtkTreeIter iter;
* gint minimum_width;
* gint natural_width;
......@@ -88,8 +85,7 @@
* valid = gtk_tree_model_iter_next (model, &iter);
* }
* gtk_cell_area_context_get_preferred_width (context, &minimum_width, &natural_width);
* ]|
* </example>
* ]|
* Note that in this example it's not important to observe the
* returned minimum and natural width of the area for each row
* unless the cell-layouting object is actually interested in the
......@@ -102,15 +98,13 @@
* exceedingly large amount of rows. The #GtkCellLayout widget in
* that case would calculate the required width of the rows in an
* idle or timeout source (see g_timeout_add()) and when the widget
* is requested its actual width in #GtkWidgetClass.get_preferred_width(<!-- -->)
* is requested its actual width in #GtkWidgetClass.get_preferred_width()
* it can simply consult the width accumulated so far in the
* #GtkCellAreaContext object.
*
* A simple example where rows are rendered from top to bottom and
* take up the full width of the layouting widget would look like:
* <example>
* <title>A typical get_preferred_width(<!-- -->) implementation</title>
* |[<!-- language="C" -->
* |[<!-- language="C" -->
* static void
* foo_get_preferred_width (GtkWidget *widget,
* gint *minimum_size,
......@@ -123,8 +117,7 @@
*
* gtk_cell_area_context_get_preferred_width (priv->context, minimum_size, natural_size);
* }
* ]|
* </example>
* ]|
* In the above example the Foo widget has to make sure that some
* row sizes have been calculated (the amount of rows that Foo judged
* was appropriate to request space for in a single timeout iteration)
......@@ -140,9 +133,7 @@
*
* In order to request the height for width of all the rows at the
* root level of a #GtkTreeModel one would do the following:
* <example>
* <title>Requesting the height for width of a handful of GtkTreeModel rows</title>
* |[<!-- language="C" -->
* |[<!-- language="C" -->
* GtkTreeIter iter;
* gint minimum_height;
* gint natural_height;
......@@ -164,8 +155,7 @@
*
* valid = gtk_tree_model_iter_next (model, &iter);
* }
* ]|
* </example>
* ]|
* Note that in the above example we would need to cache the heights
* returned for each row so that we would know what sizes to render the
* areas for each row. However we would only want to really cache the
......@@ -180,26 +170,22 @@
* synchronously. The reasoning here is that any layouting widget is
* at least capable of synchronously calculating enough height to fill
* the screen height (or scrolled window height) in response to a single
* call to #GtkWidgetClass.get_preferred_height_for_width(<!-- -->). Returning
* call to #GtkWidgetClass.get_preferred_height_for_width(). Returning
* a perfect height for width that is larger than the screen area is
* inconsequential since after the layouting receives an allocation
* from a scrolled window it simply continues to drive the scrollbar
* values while more and more height is required for the row heights
* that are calculated in the background.
* </para>
* </refsect2>
* <refsect2 id="cell-area-rendering">
* <title>Rendering Areas</title>
* <para>
*
* ## Rendering Areas
*
* Once area sizes have been aquired at least for the rows in the
* visible area of the layouting widget they can be rendered at
* #GtkWidgetClass.draw() time.
*
* A crude example of how to render all the rows at the root level
* runs as follows:
* <example>
* <title>Requesting the width of a handful of GtkTreeModel rows</title>
* |[<!-- language="C" -->
* |[<!-- language="C" -->
* GtkAllocation allocation;
* GdkRectangle cell_area = { 0, };
* GtkTreeIter iter;
......@@ -222,19 +208,16 @@
*
* valid = gtk_tree_model_iter_next (model, &iter);
* }
* ]|
* </example>
* ]|
* Note that the cached height in this example really depends on how
* the layouting widget works. The layouting widget might decide to
* give every row its minimum or natural height or, if the model content
* is expected to fit inside the layouting widget without scrolling, it
* would make sense to calculate the allocation for each row at
* #GtkWidget::size-allocate time using gtk_distribute_natural_allocation().
* </para>
* </refsect2>
* <refsect2 id="cell-area-events-and-focus">
* <title>Handling Events and Driving Keyboard Focus</title>
* <para>
*
* ## Handling Events and Driving Keyboard Focus
*
* Passing events to the area is as simple as handling events on any
* normal widget and then passing them to the gtk_cell_area_event()
* API as they come in. Usually #GtkCellArea is only interested in
......@@ -262,9 +245,7 @@
*
* A basic example of how the #GtkWidgetClass.focus() virtual method
* should be implemented:
* <example>
* <title>Implementing keyboard focus navigation</title>
* |[<!-- language="C" -->
* |[<!-- language="C" -->
* static gboolean
* foo_focus (GtkWidget *widget,
* GtkDirectionType direction)
......@@ -320,18 +301,15 @@
* }
* return have_focus;
* }
* ]|
* </example>
* ]|
* Note that the layouting widget is responsible for matching the
* GtkDirectionType values to the way it lays out its cells.
* </para>
* </refsect2>
* <refsect2 id="cell-properties">
* <title>Cell Properties</title>
* <para>
* The #GtkCellArea introduces cell properties
* for #GtkCellRenderers in very much the same way that #GtkContainer
* introduces <link linkend="child-properties">child properties</link>
*
* ## Cell Properties
*
* The #GtkCellArea introduces cell properties for #GtkCellRenderers
* in very much the same way that #GtkContainer introduces
* <link linkend="child-properties">child properties</link>
* for #GtkWidgets. This provides some general interfaces for defining
* the relationship cell areas have with their cells. For instance in a
* #GtkCellAreaBox a cell might "expand" and receive extra space when
......@@ -348,8 +326,6 @@
* gtk_cell_area_cell_set() or gtk_cell_area_cell_set_valist(). To obtain
* the value of a cell property, use gtk_cell_area_cell_get_property(),
* gtk_cell_area_cell_get() or gtk_cell_area_cell_get_valist().
* </para>
* </refsect2>
*/
#include "config.h"
......
......@@ -21,22 +21,21 @@
* @Title: GtkCellLayout
*
* #GtkCellLayout is an interface to be implemented by all objects which
* want to provide a #GtkTreeViewColumn<!-- -->-like API for packing cells, setting
* attributes and data funcs.
* want to provide a #GtkTreeViewColumn like API for packing cells,
* setting attributes and data funcs.
*
* One of the notable features provided by implementations of GtkCellLayout
* are attributes. Attributes let you set the properties
* One of the notable features provided by implementations of
* GtkCellLayout are attributes. Attributes let you set the properties
* in flexible ways. They can just be set to constant values like regular
* properties. But they can also be mapped to a column of the underlying
* tree model with gtk_cell_layout_set_attributes(), which means that the value
* of the attribute can change from cell to cell as they are rendered by the
* cell renderer. Finally, it is possible to specify a function with
* gtk_cell_layout_set_cell_data_func() that is called to determine the value
* of the attribute for each cell that is rendered.
*
* <refsect2 id="GtkCellLayout-BUILDER-UI">
* <title>GtkCellLayouts as GtkBuildable</title>
* <para>
* of the attribute can change from cell to cell as they are rendered by
* the cell renderer. Finally, it is possible to specify a function with
* gtk_cell_layout_set_cell_data_func() that is called to determine the
* value of the attribute for each cell that is rendered.
*
* ## GtkCellLayouts as GtkBuildable
*
* Implementations of GtkCellLayout which also implement the GtkBuildable
* interface (#GtkCellView, #GtkIconView, #GtkComboBox,
* #GtkEntryCompletion, #GtkTreeViewColumn) accept GtkCellRenderer objects
......@@ -46,8 +45,7 @@
* a name attribute which specifies a property of the cell renderer; the
* content of the element is the attribute value.
*
* <example>
* <title>A UI definition fragment specifying attributes</title>
* This is an example of a UI definition fragment specifying attributes:
* |[
* <object class="GtkCellView">
* <child>
......@@ -58,15 +56,15 @@
* </child>"
* </object>
* ]|
* </example>
*
* Furthermore for implementations of GtkCellLayout that use a #GtkCellArea
* to lay out cells (all GtkCellLayouts in GTK+ use a GtkCellArea)
* <link linkend="cell-properties">cell properties</link> can also be defined
* in the format by specifying the custom &lt;cell-packing&gt; attribute which
* can contain multiple &lt;property&gt; elements defined in the normal way.
* <example>
* <title>A UI definition fragment specifying cell properties</title>
*
* Furthermore for implementations of GtkCellLayout that use a
* #GtkCellArea to lay out cells (all GtkCellLayouts in GTK+ use
* a GtkCellArea) <link linkend="cell-properties">cell properties</link>
* can also be defined in the format by specifying the custom
* &lt;cell-packing&gt; attribute which can contain multiple
* &lt;property&gt; elements defined in the normal way.
*
* Here is a UI definition fragment specifying cell properties:
* |[
* <object class="GtkTreeViewColumn">
* <child>
......@@ -78,13 +76,9 @@
* </child>"
* </object>
* ]|
* </example>
* </para>
* </refsect2>
*
* <refsect2>
* <title>Subclassing GtkCellLayout implementations</title>
* <para>
* ## Subclassing GtkCellLayout implementations
*
* When subclassing a widget that implements #GtkCellLayout like
* #GtkIconView or #GtkComboBox, there are some considerations related
* to the fact that these widgets internally use a #GtkCellArea.
......@@ -128,8 +122,6 @@
* to support alternative cell areas, you can do so by moving the
* problematic calls out of init() and into a constructor()
* for your class.
* </para>
* </refsect2>
*/
#include "config.h"
......
......@@ -52,9 +52,8 @@
* You should not call gtk_combo_box_set_model() or attempt to pack more cells
* into this combo box via its GtkCellLayout interface.
*
* <refsect2 id="GtkComboBoxText-BUILDER-UI">
* <title>GtkComboBoxText as GtkBuildable</title>
* <para>
* ## GtkComboBoxText as GtkBuildable
*
* The GtkComboBoxText implementation of the GtkBuildable interface
* supports adding items directly using the &lt;items&gt; element
* and specifying &lt;item&gt; elements for each item. Each &lt;item&gt;
......@@ -62,8 +61,7 @@
* also supports the regular translation attributes "translatable",
* "context" and "comments".
*
* <example>
* <title>A UI definition fragment specifying GtkComboBoxText items</title>
* Here is a a UI definition fragment specifying GtkComboBoxText items:
* |[
* <object class="GtkComboBoxText">
* <items>
......@@ -73,9 +71,6 @@
* </items>
* </object>
* ]|
* </example>
* </para>
* </refsect2>
*/
static void gtk_combo_box_text_buildable_interface_init (GtkBuildableIface *iface);
......
......@@ -78,9 +78,8 @@
* children in a horizontal row, and a #GtkGrid arranges the widgets it contains
* in a two-dimensional grid.
*
* <refsect2 id="container-geometry-management">
* <title>Height for width geometry management</title>
* <para>
* ## Height for width geometry management
*
* GTK+ uses a height-for-width (and width-for-height) geometry management system.
* Height-for-width means that a widget can change how much vertical space it needs,
* depending on the amount of horizontal space that it is given (and similar for
......@@ -151,7 +150,7 @@
*
* Height for width requests are generally implemented in terms of a virtual allocation
* of widgets in the input orientation. Assuming an height-for-width request mode, a container
* would implement the get_preferred_height_for_width(<!-- -->) virtual function by first calling
* would implement the get_preferred_height_for_width() virtual function by first calling
* gtk_widget_get_preferred_width() for each of its children.
*
* For each potential group of children that are lined up horizontally, the values returned by
......@@ -180,11 +179,9 @@
*
* See <link linkend="geometry-management">GtkWidget's geometry management section</link>
* to learn more about implementing height-for-width geometry management for widgets.
* </para>
* </refsect2>
* <refsect2 id="child-properties">
* <title>Child properties</title>
* <para>
*
* ## Child properties
*
* GtkContainer introduces child properties.
* These are object properties that are not specific
* to either the container or the contained widget, but rather to their relation.
......@@ -202,17 +199,15 @@
* gtk_container_child_get_property(), gtk_container_child_get() or
* gtk_container_child_get_valist(). To emit notification about child property
* changes, use gtk_widget_child_notify().
* </para>
* </refsect2>
* <refsect2 id="GtkContainer-BUILDER-UI">
* <title>GtkContainer as GtkBuildable</title>
* <para>
*
* ## GtkContainer as GtkBuildable
*
* The GtkContainer implementation of the GtkBuildable interface
* supports a &lt;packing&gt; element for children, which can
* contain multiple &lt;property&gt; elements that specify
* child properties for the child.
* <example>
* <title>Child properties in UI definitions</title>
*
* An example of child properties in UI definitions:
* |[
* <object class="GtkVBox">
* <child>
......@@ -223,12 +218,10 @@
* </child>
* </object>
* ]|
* </example>
*
* Since 2.16, child properties can also be marked as translatable using
* the same "translatable", "comments" and "context" attributes that are used
* for regular properties.
* </para>
* </refsect2>
*/
......
This diff is collapsed.
......@@ -63,8 +63,8 @@
*
* #GtkDialog boxes are created with a call to gtk_dialog_new() or
* gtk_dialog_new_with_buttons(). gtk_dialog_new_with_buttons() is
* recommended; it allows you to set the dialog title, some convenient flags,
* and add simple buttons.
* recommended; it allows you to set the dialog title, some convenient
* flags, and add simple buttons.
*
* If 'dialog' is a newly created dialog, the two primary areas of the
* window can be accessed through gtk_dialog_get_content_area() and
......@@ -96,8 +96,8 @@
* use #GtkMessageDialog to save yourself some effort. But you'd need to
* create the dialog contents manually if you had more than a simple message
* in the dialog.
* <example>
* <title>Simple GtkDialog usage</title>
*
* An example for simple GtkDialog usage:
* |[<!-- language="C" -->
* /&ast; Function to open a dialog box displaying the message provided. &ast;/
* void
......@@ -127,22 +127,19 @@
* gtk_widget_show_all (dialog);
* }
* ]|
* </example>
*
* <refsect2 id="GtkDialog-BUILDER-UI"><title>GtkDialog as GtkBuildable</title>
* <para>
* ## GtkDialog as GtkBuildable
*
* The GtkDialog implementation of the #GtkBuildable interface exposes the
* @vbox and @action_area as internal children with the names "vbox" and
* "action_area".
* </para>
* <para>
*
* GtkDialog supports a custom &lt;action-widgets&gt; element, which
* can contain multiple &lt;action-widget&gt; elements. The "response"
* attribute specifies a numeric response, and the content of the element
* is the id of widget (which should be a child of the dialogs @action_area).
* </para>
* <example>
* <title>A #GtkDialog UI definition fragment.</title>
*
* An example of a #GtkDialog UI definition fragment:
* |[
* <object class="GtkDialog" id="dialog1">
* <child internal-child="vbox">
......@@ -165,8 +162,6 @@
* </action-widgets>
* </object>
* ]|
* </example>
* </refsect2>
*/
struct _GtkDialogPrivate
......
......@@ -32,9 +32,8 @@
* to add it to the expander. When the expander is toggled, it will take
* care of showing and hiding the child automatically.
*
* <refsect2 id="expander-special-usage">
* <title>Special Usage</title>
* <para>
* ## Special Usage
*
* There are situations in which you may prefer to show and hide the
* expanded widget yourself, such as when you want to actually create
* the widget at expansion time. In this case, create a #GtkExpander
......@@ -42,7 +41,7 @@
* #GtkExpander:expanded property which can be used to monitor
* its expansion state. You should watch this property with a signal
* connection as follows:
* </para>
*
* |[<!-- language="C" -->
* expander = gtk_expander_new_with_mnemonic ("_More Options");
* g_signal_connect (expander, "notify::expanded",
......@@ -69,18 +68,16 @@
* }
* }
* ]|
* </refsect2>
* <refsect2 id="GtkExpander-BUILDER-UI">
* <title>GtkExpander as GtkBuildable</title>
* <para>
*
* ## GtkExpander as GtkBuildable
*
* The GtkExpander implementation of the GtkBuildable interface
* supports placing a child in the label position by specifying
* "label" as the "type" attribute of a &lt;child&gt; element.
* A normal content child can be specified without specifying
* a &lt;child&gt; type attribute.
* </para>
* <example>
* <title>A UI definition fragment with GtkExpander</title>
*
* An example of a UI definition fragment with GtkExpander:
* |[