AuroraMiddleware/gtk
1
0
Fork 1
mirror of https://gitlab.gnome.org/GNOME/gtk.git synced 2025-01-15 23:00:08 +00:00
Code Issues Projects Releases Wiki Activity

Merge branch 'docs-label' into 'master'

Browse Source 
Various documentation fixes

See merge request GNOME/gtk!4029
This commit is contained in:
Matthias Clasen 2021-10-04 12:25:41 +00:00
commit bb5eb3ba55
8 changed files with 131 additions and 124 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

138
gtk/gtkcellarea.c
View File

@ -22,12 +22,12 @@
/**
* GtkCellArea:
*
* An abstract class for laying out GtkCellRenderers
* An abstract class for laying out `GtkCellRenderer`s
*
* The `GtkCellArea` is an abstract class for `GtkCellLayout` widgets
* (also referred to as "layouting widgets") to interface with an
* arbitrary number of `GtkCellRenderer`s and interact with the user
* for a given `GtkTreeModel` row.
* The `GtkCellArea` is an abstract class for [class@Gtk.CellLayout]
* widgets (also referred to as "layouting widgets") to interface with
* an arbitrary number of [class@Gtk.CellRenderer]s and interact with the user
* for a given [iface@Gtk.TreeModel] row.
*
* The cell area handles events, focus navigation, drawing and
* size requests and allocations for a given row of data.
@ -38,7 +38,7 @@
* # Requesting area sizes
*
* As outlined in
* [GtkWidget’s geometry management section][geometry-management],
* [GtkWidget’s geometry management section](class.Widget.html#height-for-width-geometry-management),
* GTK uses a height-for-width
* geometry management system to compute the sizes of widgets and user
* interfaces. `GtkCellArea` uses the same semantics to calculate the
@ -46,8 +46,8 @@
*
* When requesting the size of a cell area one needs to calculate
* the size for a handful of rows, and this will be done differently by
* different layouting widgets. For instance a `GtkTreeViewColumn`
* always lines up the areas from top to bottom while a `GtkIconView`
* different layouting widgets. For instance a [class@Gtk.TreeViewColumn]
* always lines up the areas from top to bottom while a [class@Gtk.IconView]
* on the other hand might enforce that all areas received the same
* width and wrap the areas around, requesting height for more cell
* areas when allocated less width.
@ -56,27 +56,28 @@
* alignments with areas rendered for adjacent rows (cells can
* appear “columnized” inside an area even when the size of
* cells are different in each row). For this reason the `GtkCellArea`
* uses a `GtkCellArea`Context object to store the alignments
* uses a [class@Gtk.CellAreaContext] object to store the alignments
* and sizes along the way (as well as the overall largest minimum
* and natural size for all the rows which have been calculated
* with the said context).
*
* The `GtkCellArea`Context is an opaque object specific to the
* `GtkCellArea` which created it (see gtk_cell_area_create_context()).
* The [class@Gtk.CellAreaContext] is an opaque object specific to the
* `GtkCellArea` which created it (see [method@Gtk.CellArea.create_context]).
*
* The owning cell-layouting widget can create as many contexts as
* it wishes to calculate sizes of rows which should receive the
* same size in at least one orientation (horizontally or vertically),
* However, it’s important that the same `GtkCellArea`Context which
* However, it’s important that the same [class@Gtk.CellAreaContext] which
* was used to request the sizes for a given `GtkTreeModel` row be
* used when rendering or processing events for that row.
*
* In order to request the width of all the rows at the root level
* of a `GtkTreeModel` one would do the following:
*
* |[<!-- language="C" -->
* ```c
* GtkTreeIter iter;
* int minimum_width;
* int natural_width;
* int minimum_width;
* int natural_width;
*
* valid = gtk_tree_model_get_iter_first (model, &iter);
* while (valid)
@ -86,51 +87,52 @@
*
* valid = gtk_tree_model_iter_next (model, &iter);
* }
*
* gtk_cell_area_context_get_preferred_width (context, &minimum_width, &natural_width);
* ]|
* ```
*
* 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
* widths of individual rows. The overall width is however stored
* in the accompanying `GtkCellArea`Context object and can be consulted
* in the accompanying `GtkCellAreaContext` object and can be consulted
* at any time.
*
* This can be useful since `GtkCellLayout` widgets usually have to
* support requesting and rendering rows in treemodels with an
* 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
* idle or timeout source (see [func@GLib.timeout_add]) and when the widget
* is requested its actual width in [vfunc@Gtk.Widget.measure]
* it can simply consult the width accumulated so far in the
* `GtkCellArea`Context object.
* `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:
*
* |[<!-- language="C" -->
* ```c
* static void
* foo_get_preferred_width (GtkWidget *widget,
* int *minimum_size,
* int *natural_size)
* foo_get_preferred_width (GtkWidget *widget,
* int *minimum_size,
* int *natural_size)
* {
* Foo *foo = FOO (widget);
* FooPrivate *priv = foo->priv;
* Foo *self = FOO (widget);
* FooPrivate *priv = foo_get_instance_private (self);
*
* foo_ensure_at_least_one_handfull_of_rows_have_been_requested (foo);
* foo_ensure_at_least_one_handfull_of_rows_have_been_requested (self);
*
* gtk_cell_area_context_get_preferred_width (priv->context, minimum_size, natural_size);
* }
* ]|
* ```
*
* 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
* 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)
* before simply returning the amount of space required by the area via
* the `GtkCellArea`Context.
* the `GtkCellAreaContext`.
*
* Requesting the height for width (or width for height) of an area is
* a similar task except in this case the `GtkCellArea`Context does not
* a similar task except in this case the `GtkCellAreaContext` does not
* store the data (actually, it does not know how much space the layouting
* widget plans to allocate it for every row. It’s up to the layouting
* widget to render each row of data with the appropriate height and
@ -139,12 +141,12 @@
* In order to request the height for width of all the rows at the
* root level of a `GtkTreeModel` one would do the following:
*
* |[<!-- language="C" -->
* ```c
* GtkTreeIter iter;
* int minimum_height;
* int natural_height;
* int full_minimum_height = 0;
* int full_natural_height = 0;
* int minimum_height;
* int natural_height;
* int full_minimum_height = 0;
* int full_natural_height = 0;
*
* valid = gtk_tree_model_get_iter_first (model, &iter);
* while (valid)
@ -161,7 +163,7 @@
*
* valid = gtk_tree_model_iter_next (model, &iter);
* }
* ]|
* ```
*
* 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
@ -193,12 +195,12 @@
* A crude example of how to render all the rows at the root level
* runs as follows:
*
* |[<!-- language="C" -->
* ```c
* GtkAllocation allocation;
* GdkRectangle cell_area = { 0, };
* GtkTreeIter iter;
* int minimum_width;
* int natural_width;
* GdkRectangle cell_area = { 0, };
* GtkTreeIter iter;
* int minimum_width;
* int natural_width;
*
* gtk_widget_get_allocation (widget, &allocation);
* cell_area.width = allocation.width;
@ -216,31 +218,31 @@
*
* valid = gtk_tree_model_iter_next (model, &iter);
* }
* ]|
* ```
*
* 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
* the time the widget is allocated using gtk_distribute_natural_allocation().
* the time the widget is allocated using [func@Gtk.distribute_natural_allocation].
*
* # 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()
* normal widget and then passing them to the [method@Gtk.CellArea.event]
* API as they come in. Usually `GtkCellArea` is only interested in
* button events, however some customized derived areas can be implemented
* who are interested in handling other events. Handling an event can
* trigger the `GtkCellArea`::focus-changed signal to fire; as well as
* `GtkCellArea`::add-editable in the case that an editable cell was
* clicked and needs to start editing. You can call
* gtk_cell_area_stop_editing() at any time to cancel any cell editing
* trigger the [`signal@Gtk.CellArea::focus-changed`] signal to fire; as well
* as [`signal@GtkCellArea::add-editable`] in the case that an editable cell
* was clicked and needs to start editing. You can call
* [method@Gtk.CellArea.stop_editing] at any time to cancel any cell editing
* that is currently in progress.
*
* The `GtkCellArea` drives keyboard focus from cell to cell in a way
* similar to `GtkWidget`. For layouting widgets that support giving
* focus to cells it’s important to remember to pass %GTK_CELL_RENDERER_FOCUSED
* focus to cells it’s important to remember to pass `GTK_CELL_RENDERER_FOCUSED`
* to the area functions for the row that has focus and to tell the
* area to paint the focus at render time.
*
@ -249,23 +251,21 @@
* responsible for knowing where `GtkTreeModel` rows are rendered inside
* the widget, so at [vfunc@Gtk.Widget.focus] time the layouting widget
* should use the `GtkCellArea` methods to navigate focus inside the area
* and then observe the GtkDirectionType to pass the focus to adjacent
* and then observe the [enum@Gtk.DirectionType] to pass the focus to adjacent
* rows and areas.
*
* A basic example of how the [vfunc@Gtk.Widget.focus] virtual method
* should be implemented:
*
* |[<!-- language="C" -->
* ```
* static gboolean
* foo_focus (GtkWidget *widget,
* GtkDirectionType direction)
* {
* Foo *foo = FOO (widget);
* FooPrivate *priv = foo->priv;
* int focus_row;
* gboolean have_focus = FALSE;
*
* focus_row = priv->focus_row;
* Foo *self = FOO (widget);
* FooPrivate *priv = foo_get_instance_private (self);
* int focus_row = priv->focus_row;
* gboolean have_focus = FALSE;
*
* if (!gtk_widget_has_focus (widget))
* gtk_widget_grab_focus (widget);
@ -311,30 +311,30 @@
* }
* return have_focus;
* }
* ]|
* ```
*
* Note that the layouting widget is responsible for matching the
* GtkDirectionType values to the way it lays out its cells.
* `GtkDirectionType` values to the way it lays out its cells.
*
* # Cell Properties
*
* The `GtkCellArea` introduces cell properties for `GtkCellRenderer`s.
* This provides some general interfaces for defining the relationship
* cell areas have with their cells. For instance in a `GtkCellArea`Box
* cell areas have with their cells. For instance in a [class@Gtk.CellAreaBox]
* a cell might “expand” and receive extra space when the area is allocated
* more than its full natural request, or a cell might be configured to “align”
* with adjacent rows which were requested and rendered with the same
* `GtkCellArea`Context.
* `GtkCellAreaContext`.
*
* Use gtk_cell_area_class_install_cell_property() to install cell
* properties for a cell area class and gtk_cell_area_class_find_cell_property()
* or gtk_cell_area_class_list_cell_properties() to get information about
* Use [method@Gtk.CellAreaClass.install_cell_property] to install cell
* properties for a cell area class and [method@Gtk.CellAreaClass.find_cell_property]
* or [method@Gtk.CellAreaClass.list_cell_properties] to get information about
* existing cell properties.
*
* To set the value of a cell property, use gtk_cell_area_cell_set_property(),
* 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().
* To set the value of a cell property, use [method@Gtk.CellArea.cell_set_property],
* [method@Gtk.CellArea.cell_set] or [method@Gtk.CellArea.cell_set_valist]. To obtain
* the value of a cell property, use [method@Gtk.CellArea.cell_get_property]
* [method@Gtk.CellArea.cell_get] or [method@Gtk.CellArea.cell_get_valist].
*/
#include "config.h"

47
gtk/gtkcelllayout.c
View File

@ -39,33 +39,34 @@
* Implementations of GtkCellLayout which also implement the GtkBuildable
* interface (`GtkCellView`, `GtkIconView`, `GtkComboBox`,
* `GtkEntryCompletion`, `GtkTreeViewColumn`) accept `GtkCellRenderer` objects
* as <child> elements in UI definitions. They support a custom <attributes>
* element for their children, which can contain multiple <attribute>
* elements. Each <attribute> element has a name attribute which specifies
* as `<child>` elements in UI definitions. They support a custom `<attributes>`
* element for their children, which can contain multiple `<attribute>`
* elements. Each `<attribute>` element has a name attribute which specifies
* a property of the cell renderer; the content of the element is the
* attribute value.
*
* This is an example of a UI definition fragment specifying attributes:
* |[
*
* ```xml
* <object class="GtkCellView">
* <child>
* <object class="GtkCellRendererText"/>
* <attributes>
* <attribute name="text">0</attribute>
* </attributes>
* </child>"
* </child>
* </object>
* ]|
* ```
*
* Furthermore for implementations of GtkCellLayout that use a `GtkCellArea`
* to lay out cells (all GtkCellLayouts in GTK use a GtkCellArea)
* [cell properties][cell-properties] can also be defined in the format by
* specifying the custom <cell-packing> attribute which can contain multiple
* <property> elements defined in the normal way.
* Furthermore for implementations of `GtkCellLayout` that use a `GtkCellArea`
* to lay out cells (all `GtkCellLayout`s in GTK use a `GtkCellArea`)
* [cell properties](class.CellArea.html#cell-properties) can also be defined
* in the format by specifying the custom `<cell-packing>` attribute which can
* contain multiple `<property>` elements.
*
* Here is a UI definition fragment specifying cell properties:
*
* |[
* ```xml
* <object class="GtkTreeViewColumn">
* <child>
* <object class="GtkCellRendererText"/>
@ -73,9 +74,9 @@
* <property name="align">True</property>
* <property name="expand">False</property>
* </cell-packing>
* </child>"
* </child>
* </object>
* ]|
* ```
*
* # Subclassing GtkCellLayout implementations
*
@ -85,25 +86,27 @@
* The cell area is exposed as a construct-only property by these
* widgets. This means that it is possible to e.g. do
*
* |[<!-- language="C" -->
* combo = g_object_new (GTK_TYPE_COMBO_BOX, "cell-area", my_cell_area, NULL);
* ]|
* ```c
* GtkWIdget *combo =
* g_object_new (GTK_TYPE_COMBO_BOX, "cell-area", my_cell_area, NULL);
* ```
*
* to use a custom cell area with a combo box. But construct properties
* are only initialized after instance init()
* are only initialized after instance `init()`
* functions have run, which means that using functions which rely on
* the existence of the cell area in your subclass’ init() function will
* the existence of the cell area in your subclass `init()` function will
* cause the default cell area to be instantiated. In this case, a provided
* construct property value will be ignored (with a warning, to alert
* you to the problem).
*
* |[<!-- language="C" -->
* ```c
* static void
* my_combo_box_init (MyComboBox *b)
* {
* GtkCellRenderer *cell;
*
* cell = gtk_cell_renderer_pixbuf_new ();
*
* // The following call causes the default cell area for combo boxes,
* // a GtkCellAreaBox, to be instantiated
* gtk_cell_layout_pack_start (GTK_CELL_LAYOUT (b), cell, FALSE);
@ -116,12 +119,12 @@
* // This call is going to cause a warning about area being ignored
* return g_object_new (MY_TYPE_COMBO_BOX, "cell-area", area, NULL);
* }
* ]|
* ```
*
* If supporting alternative cell areas with your derived widget is
* not important, then this does not have to concern you. If you want
* to support alternative cell areas, you can do so by moving the
* problematic calls out of init() and into a constructor()
* problematic calls out of `init()` and into a `constructor()`
* for your class.
*/

7
gtk/gtkdrawingarea.c
View File

@ -129,9 +129,10 @@ static guint signals[LAST_SIGNAL] = { 0, };
* drawing area’s window using [method@Gtk.Widget.queue_draw].
* This will cause the drawing area to call the draw function again.
*
* The available routines for drawing are documented on the
* [GDK Drawing Primitives][gdk4-Cairo-Interaction] page
* and the cairo documentation.
* The available routines for drawing are documented in the
* [Cairo documentation](https://www.cairographics.org/manual/); GDK
* offers additional API to integrate with Cairo, like [func@Gdk.cairo_set_source_rgba]
* or [func@Gdk.cairo_set_source_pixbuf].
*
* To receive mouse events on a drawing area, you will need to use
* event controllers. To receive keyboard events, you will need to set

4
gtk/gtklabel.c
View File

@ -2380,7 +2380,7 @@ gtk_label_class_init (GtkLabelClass *class)
*
* If this property is set to -1, the width will be calculated automatically.
*
* See the section on [text layout][label-text-layout] for details of how
* See the section on [text layout](#text-layout) for details of how
* [property@Gtk.Label:width-chars] and [property@Gtk.Label:max-width-chars]
* determine the width of ellipsized and wrapped labels.
*/
@ -2416,7 +2416,7 @@ gtk_label_class_init (GtkLabelClass *class)
*
* If this property is set to -1, the width will be calculated automatically.
*
* See the section on [text layout][label-text-layout] for details of how
* See the section on [text layout](#text-layout) for details of how
* [property@Gtk.Label:width-chars] and [property@Gtk.Label:max-width-chars]
* determine the width of ellipsized and wrapped labels.
*/

40
gtk/gtkliststore.c
View File

@ -32,28 +32,29 @@
/**
* GtkListStore:
*
* A list-like data structure that can be used with the GtkTreeView
* A list-like data structure that can be used with the [class@Gtk.TreeView].
*
* The `GtkListStore` object is a list model for use with a `GtkTreeView`
* widget. It implements the `GtkTreeModel` interface, and consequentialy,
* can use all of the methods available there. It also implements the
* `GtkTreeSortable` interface so it can be sorted by the view.
* Finally, it also implements the tree
* [drag and drop][gtk4-GtkTreeView-drag-and-drop]
* [drag](iface.TreeDragSource.html) and [drop](iface.TreeDragDest.html)
* interfaces.
*
* The `GtkListStore` can accept most GObject types as a column type, though
* The `GtkListStore` can accept most `GType`s as a column type, though
* it can’t accept all custom types. Internally, it will keep a copy of
* data passed in (such as a string or a boxed pointer). Columns that
* accept `GObject`s are handled a little differently. The
* `GtkListStore` will keep a reference to the object instead of copying the
* value. As a result, if the object is modified, it is up to the
* application writer to call gtk_tree_model_row_changed() to emit the
* `GtkTreeModel`::row_changed signal. This most commonly affects lists with
* `GdkTexture`s stored.
* application writer to call [method@Gtk.TreeModel.row_changed] to emit the
* [signal@Gtk.TreeModel::row_changed] signal. This most commonly affects lists
* with [class@Gdk.Texture]s stored.
*
* An example for creating a simple list store:
* |[<!-- language="C" -->
*
* ```c
* enum {
* COLUMN_STRING,
* COLUMN_INT,
@ -101,14 +102,14 @@
* COLUMN_BOOLEAN, TRUE,
* -1);
* }
* ]|
* ```
*
* # Performance Considerations
*
* Internally, the `GtkListStore` was originally implemented with a linked list
* with a tail pointer. As a result, it was fast at data insertion and deletion,
* and not fast at random data access. The `GtkListStore` sets the
* %GTK_TREE_MODEL_ITERS_PERSIST flag, which means that `GtkTreeIter`s can be
* `GTK_TREE_MODEL_ITERS_PERSIST` flag, which means that `GtkTreeIter`s can be
* cached while the row exists. Thus, if access to a particular row is needed
* often and your code is expected to run on older versions of GTK, it is worth
* keeping the iter around.
@ -120,9 +121,9 @@
* are atomic, in the sense that the row is being appended to the store and the
* values filled in in a single operation with regard to `GtkTreeModel` signaling.
* In contrast, using e.g. gtk_list_store_append() and then gtk_list_store_set()
* will first create a row, which triggers the `GtkTreeModel`::row-inserted signal
* will first create a row, which triggers the `GtkTreeModel::row-inserted` signal
* on `GtkListStore`. The row, however, is still empty, and any signal handler
* connecting to `GtkTreeModel`::row-inserted on this particular store should be prepared
* connecting to `GtkTreeModel::row-inserted` on this particular store should be prepared
* for the situation that the row might be empty. This is especially important
* if you are wrapping the `GtkListStore` inside a `GtkTreeModel`Filter and are
* using a `GtkTreeModel`FilterVisibleFunc. Using any of the non-atomic operations
@ -132,15 +133,15 @@
*
* # GtkListStore as GtkBuildable
*
* The GtkListStore implementation of the GtkBuildable interface allows
* to specify the model columns with a <columns> element that may contain
* multiple <column> elements, each specifying one model column. The “type”
* The GtkListStore implementation of the [iface@Gtk.Buildable] interface allows
* to specify the model columns with a `<columns>` element that may contain
* multiple `<column>` elements, each specifying one model column. The “type”
* attribute specifies the data type for the column.
*
* Additionally, it is possible to specify content for the list store
* in the UI definition, with the <data> element. It can contain multiple
* <row> elements, each specifying to content for one row of the list model.
* Inside a <row>, the <col> elements specify the content for individual cells.
* in the UI definition, with the `<data>` element. It can contain multiple
* `<row>` elements, each specifying to content for one row of the list model.
* Inside a `<row>`, the `<col>` elements specify the content for individual cells.
*
* Note that it is probably more common to define your models in the code,
* and one might consider it a layering violation to specify the content of
@ -148,7 +149,8 @@
* is to separate the two, as far as possible.
*
* An example of a UI Definition fragment for a list store:
* |[<!-- language="C" -->
*
* ```xml
* <object class="GtkListStore">
* <columns>
* <column type="gchararray"/>
@ -168,7 +170,7 @@
* </row>
* </data>
* </object>
* ]|
* ```
*/

7
gtk/gtktreeview.c
View File

@ -1170,17 +1170,18 @@ gtk_tree_view_class_init (GtkTreeViewClass *class)
* @column: (nullable): the `GtkTreeViewColumn` in which the activation occurred
*
* The "row-activated" signal is emitted when the method
* gtk_tree_view_row_activated() is called.
* [`method@Gtk.TreeView.row_activated`] is called.
*
* This signal is emitted when the user double-clicks a treeview row with the
* [property@Gtk.TreeView:activate-on-single-click] property set to %FALSE,
* or when the user single-clicks a row when that property set to %TRUE.
*
* This signal is also emitted when a non-editable row is selected and one
* of the keys: <kbd>Space</kbd>, <kbd>Shift</kbd>+<kbd>Space</kbd>, <kbd>Return</kbd> or <kbd>Enter</kbd> is pressed.
* of the keys: <kbd>Space</kbd>, <kbd>Shift</kbd>+<kbd>Space</kbd>,
* <kbd>Return</kbd> or <kbd>Enter</kbd> is pressed.
*
* For selection handling refer to the
* [tree widget conceptual overview][TreeWidget]
* [tree widget conceptual overview](section-tree-widget.html)
* as well as `GtkTreeSelection`.
*/
tree_view_signals[ROW_ACTIVATED] =

10
gtk/gtktreeviewcolumn.c
View File

@ -46,16 +46,16 @@
/**
* GtkTreeViewColumn:
*
* A visible column in a GtkTreeView widget
* A visible column in a [class@Gtk.TreeView] widget
*
* The GtkTreeViewColumn object represents a visible column in a `GtkTreeView` widget.
* The `GtkTreeViewColumn` object represents a visible column in a `GtkTreeView` widget.
* It allows to set properties of the column header, and functions as a holding pen
* for the cell renderers which determine how the data in the column is displayed.
*
* Please refer to the [tree widget conceptual overview][TreeWidget]
* Please refer to the [tree widget conceptual overview](section-tree-widget.html)
* for an overview of all the objects and data types related to the tree widget and
* how they work together, and to the `GtkTreeView` documentation for specifics about
* the CSS node structure for treeviews and their headers.
* how they work together, and to the [class@Gtk.TreeView] documentation for specifics
* about the CSS node structure for treeviews and their headers.
*/

2
gtk/gtkwidget.h
View File

@ -87,7 +87,7 @@ typedef gboolean (*GtkTickCallback) (GtkWidget *widget,
* @height: the widget’s desired height
*
* A `GtkRequisition` represents the desired size of a widget. See
* [GtkWidget’s geometry management section][geometry-management] for
* [GtkWidget’s geometry management section](class.Widget.html#height-for-width-geometry-management) for
* more information.
*/
struct _GtkRequisition