Commit 76447c35 authored by William Jon McCann's avatar William Jon McCann

docs: use quotes instead of <firstterm>

parent a3bad427
......@@ -58,7 +58,7 @@
* Otherwise either the core or XInput 1 implementations will be used.
*
* For simple applications that don't have any special interest in
* input devices, the so-called <firstterm>client pointer</firstterm>
* input devices, the so-called “client pointer”
* provides a reasonable approximation to a simple setup with a single
* pointer and keyboard. The device that has been set as the client
* pointer can be accessed via gdk_device_manager_get_client_pointer().
......@@ -124,7 +124,7 @@
* changes, the #GdkDevice:n-axes property will be notified, and
* gdk_device_list_axes() will return the new device axes.
*
* Devices may also have associated <firstterm>keys</firstterm> or
* Devices may also have associated “keys” or
* macro buttons. Such keys can be globally set to map into normal X
* keyboard events. The mapping is set using gdk_device_set_key().
*/
......
......@@ -65,7 +65,7 @@
* as a representation of a symbol printed on a physical keyboard key. That is, it
* contains three pieces of information. First, it contains the hardware keycode;
* this is an identifying number for a physical key. Second, it contains the
* <firstterm>level</firstterm> of the key. The level indicates which symbol on the
* “level” of the key. The level indicates which symbol on the
* key will be used, in a vertical direction. So on a standard US keyboard, the key
* with the number "1" on it also has the exclamation point ("!") character on
* it. The level indicates whether to use the "1" or the "!" symbol. The letter
......
......@@ -28,16 +28,16 @@
* @Title: Properties and Atoms
*
* Each window under X can have any number of associated
* <firstterm>properties</firstterm> attached to it.
* “properties” attached to it.
* Properties are arbitrary chunks of data identified by
* <firstterm>atom</firstterm>s. (An <firstterm>atom</firstterm>
* “atom”s. (An “atom”
* is a numeric index into a string table on the X server. They are used
* to transfer strings efficiently between clients without
* having to transfer the entire string.) A property
* has an associated type, which is also identified
* using an atom.
*
* A property has an associated <firstterm>format</firstterm>,
* A property has an associated “format”,
* an integer describing how many bits are in each unit
* of data inside the property. It must be 8, 16, or 32.
* When data is transferred between the server and client,
......
......@@ -36,14 +36,14 @@
* @Title: Selections
*
* The X selection mechanism provides a way to transfer arbitrary chunks of
* data between programs. A <firstterm>selection</firstterm> is a essentially
* data between programs. A “selection” is a essentially
* a named clipboard, identified by a string interned as a #GdkAtom. By
* claiming ownership of a selection, an application indicates that it will
* be responsible for supplying its contents. The most common selections are
* <literal>PRIMARY</literal> and <literal>CLIPBOARD</literal>.
*
* The contents of a selection can be represented in a number of formats,
* called <firstterm>targets</firstterm>. Each target is identified by an atom.
* called “targets”. Each target is identified by an atom.
* A list of all possible targets supported by the selection owner can be
* retrieved by requesting the special target <literal>TARGETS</literal>. When
* a selection is retrieved, the data is accompanied by a type (an atom), and
......
......@@ -65,7 +65,7 @@
* <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
* window. For a “composited” window it is the
* responsibility of the application to render the window contents at
* the right spot.</para>
*
......
......@@ -46,14 +46,14 @@
*
* The #GtkHandleBox widget allows a portion of a window to be "torn
* off". It is a bin widget which displays its child and a handle that
* the user can drag to tear off a separate window (the <firstterm>float
* window</firstterm>) containing the child widget. A thin
* <firstterm>ghost</firstterm> is drawn in the original location of the
* the user can drag to tear off a separate window (the float
* window) containing the child widget. A thin
* “ghost” is drawn in the original location of the
* handlebox. By dragging the separate window back to its original
* location, it can be reattached.
*
* When reattaching, the ghost and float window, must be aligned
* along one of the edges, the <firstterm>snap edge</firstterm>.
* along one of the edges, the “snap edge”.
* This either can be specified by the application programmer
* explicitly, or GTK+ will pick a reasonable default based
* on the handle position.
......
......@@ -89,7 +89,7 @@
* `--prefix` or `--sysconfdir` options when
* configuring GTK+.)
*
* The set of these <firstterm>default</firstterm> files
* The set of these “default” files
* can be retrieved with gtk_rc_get_default_files()
* and modified with gtk_rc_add_default_file() and
* gtk_rc_set_default_files().
......@@ -118,8 +118,8 @@
* ]|
*
* attaches the style <literal>"my-entry-class"</literal> to all
* widgets whose <firstterm>widget path</firstterm> matches the
* <firstterm>pattern</firstterm> <literal>"mywindow.*.GtkEntry"</literal>.
* widgets whose “widget path” matches the
* “pattern” <literal>"mywindow.*.GtkEntry"</literal>.
* That is, all #GtkEntry widgets which are part of a #GtkWindow named
* <literal>"mywindow"</literal>.
*
......@@ -127,7 +127,7 @@
* The <literal>"?"</literal> wildcard matches any character, while
* <literal>"*"</literal> matches zero or more of any character.
* The three types of matching are against the widget path, the
* <firstterm>class path</firstterm> and the class hierarchy. Both the
* “class path” and the class hierarchy. Both the
* widget path and the class path consist of a <literal>"."</literal>
* separated list of all the parents of the widget and the widget itself
* from outermost to innermost. The difference is that in the widget path,
......
......@@ -49,8 +49,8 @@
* automatically sets up the accelerators for your menus in the ui
* manager's #GtkAccelGroup.
*
* Note that <firstterm>accelerators</firstterm> are different from
* <firstterm>mnemonics</firstterm>. Accelerators are shortcuts for
* Note that “accelerators” are different from
* “mnemonics”. Accelerators are shortcuts for
* activating a menu item; they appear alongside the menu item they're a
* shortcut for. For example "Ctrl+Q" might appear alongside the "Quit"
* menu item. Mnemonics are shortcuts for GUI elements such as text
......
......@@ -61,8 +61,8 @@
* GtkBuilder parses textual descriptions of user interfaces which are
* specified in an XML format which can be roughly described by the
* RELAX NG schema below. We refer to these descriptions as
* <firstterm>GtkBuilder UI definitions</firstterm> or just
* <firstterm>UI definitions</firstterm> if the context is clear.
* “GtkBuilder UI definitions” or just
* “UI definitions” if the context is clear.
* Do not confuse GtkBuilder UI Definitions with
* <link linkend="XML-UI">GtkUIManager UI Definitions</link>, which
* are more limited in scope. It is common to use `.ui`
......
......@@ -53,9 +53,9 @@
*
* Beyond merely rendering a cell, cell renderers can optionally
* provide active user interface elements. A cell renderer can be
* <firstterm>activatable</firstterm> like #GtkCellRendererToggle,
* “activatable” like #GtkCellRendererToggle,
* which toggles when it gets activated by a mouse click, or it can be
* <firstterm>editable</firstterm> like #GtkCellRendererText, which
* “editable” like #GtkCellRendererText, which
* allows the user to edit the text using a #GtkEntry.
* To make a cell renderer activatable or editable, you have to
* implement the #GtkCellRendererClass.activate or
......
......@@ -68,7 +68,7 @@
* #GtkIconTheme provides a facility for looking up icons by name
* and size. The main reason for using a name rather than simply
* providing a filename is to allow different icons to be used
* depending on what <firstterm>icon theme</firstterm> is selected
* depending on what “icon theme” is selected
* by the user. The operation of icon themes on Linux and Unix
* follows the <ulink
* url="http://www.freedesktop.org/Standards/icon-theme-spec">Icon
......
......@@ -92,7 +92,7 @@
*
* ## Mnemonics
*
* Labels may contain <firstterm>mnemonics</firstterm>. Mnemonics are
* Labels may contain “mnemonics”. Mnemonics are
* underlined characters in the label, used for keyboard navigation.
* Mnemonics are created by providing a string with an underscore before
* the mnemonic character, such as <literal>"_File"</literal>, to the
......
......@@ -37,16 +37,16 @@
* application in text mode instead.
*
* Like all GUI toolkits, GTK+ uses an event-driven programming model. When the
* user is doing nothing, GTK+ sits in the <firstterm>main loop</firstterm> and
* user is doing nothing, GTK+ sits in the “main loop” and
* waits for input. If the user performs some action - say, a mouse click - then
* the main loop "wakes up" and delivers an event to GTK+. GTK+ forwards the
* event to one or more widgets.
*
* When widgets receive an event, they frequently emit one or more
* <firstterm>signals</firstterm>. Signals notify your program that "something
* “signals”. Signals notify your program that "something
* interesting happened" by invoking functions you've connected to the signal
* with g_signal_connect(). Functions connected to a signal are often termed
* <firstterm>callbacks</firstterm>.
* “callbacks”.
*
* When your callbacks are invoked, you would typically take some action - for
* example, when an Open button is clicked you might display a
......
......@@ -34,7 +34,7 @@
* @title: GtkOverlay
*
* GtkOverlay is a container which contains a single main child, on top
* of which it can place <firstterm>overlay</firstterm> widgets. The
* of which it can place “overlay” widgets. The
* position of each overlay widget is determined by its #GtkWidget:halign
* and #GtkWidget:valign properties. E.g. a widget with both alignments
* set to %GTK_ALIGN_START will be placed at the top left corner of the
......
......@@ -69,9 +69,9 @@
* buffer mutations, because their behavior is defined when text is inserted or
* deleted. When text containing a mark is deleted, the mark remains in the
* position originally occupied by the deleted text. When text is inserted at a
* mark, a mark with <firstterm>left gravity</firstterm> will be moved to the
* beginning of the newly-inserted text, and a mark with <firstterm>right
* gravity</firstterm> will be moved to the end.
* mark, a mark with “left gravity” will be moved to the
* beginning of the newly-inserted text, and a mark with right
* gravity will be moved to the end.
*
* Note that "left" and "right" here refer to logical direction (left
* is the toward the start of the buffer); in some languages such as
......
......@@ -238,8 +238,8 @@
*
* ## Style Properties
*
* #GtkWidget introduces <firstterm>style
* properties</firstterm> - these are basically object properties that are stored
* #GtkWidget introduces style
* properties - these are basically object properties that are stored
* not on the object, but in the style object associated to the widget. Style
* properties are set in <link linkend="gtk3-Resource-Files">resource files</link>.
* This mechanism is used for configuring such things as the location of the
......@@ -1843,7 +1843,7 @@ G_GNUC_END_IGNORE_DEPRECATIONS
*
* The ::hierarchy-changed signal is emitted when the
* anchored state of a widget changes. A widget is
* <firstterm>anchored</firstterm> when its toplevel
* “anchored” when its toplevel
* ancestor is a #GtkWindow. This signal is emitted when
* a widget changes from un-anchored to anchored or vice-versa.
*/
......
Markdown is supported
0% or
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment