diff --git a/gdk/gdkdevicemanager.c b/gdk/gdkdevicemanager.c index 171aa3acbb..80a3f0b146 100644 --- a/gdk/gdkdevicemanager.c +++ b/gdk/gdkdevicemanager.c @@ -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 client pointer + * 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 keys 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(). */ diff --git a/gdk/gdkkeys.c b/gdk/gdkkeys.c index 568cf3a0ad..da5664c6a8 100644 --- a/gdk/gdkkeys.c +++ b/gdk/gdkkeys.c @@ -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 - * level 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 diff --git a/gdk/gdkproperty.c b/gdk/gdkproperty.c index b0a4741025..9453c954ab 100644 --- a/gdk/gdkproperty.c +++ b/gdk/gdkproperty.c @@ -28,16 +28,16 @@ * @Title: Properties and Atoms * * Each window under X can have any number of associated - * properties attached to it. + * “properties” attached to it. * Properties are arbitrary chunks of data identified by - * atoms. (An atom + * “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 format, + * 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, diff --git a/gdk/gdkselection.c b/gdk/gdkselection.c index cfd88a1882..28f46f8d63 100644 --- a/gdk/gdkselection.c +++ b/gdk/gdkselection.c @@ -36,14 +36,14 @@ * @Title: Selections * * The X selection mechanism provides a way to transfer arbitrary chunks of - * data between programs. A selection 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 * PRIMARY and CLIPBOARD. * * The contents of a selection can be represented in a number of formats, - * called targets. 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 TARGETS. When * a selection is retrieved, the data is accompanied by a type (an atom), and diff --git a/gdk/gdkwindow.c b/gdk/gdkwindow.c index 68aceae762..8bbe482a89 100644 --- a/gdk/gdkwindow.c +++ b/gdk/gdkwindow.c @@ -65,7 +65,7 @@ * 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 composited 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. * diff --git a/gtk/deprecated/gtkhandlebox.c b/gtk/deprecated/gtkhandlebox.c index 521bb8e0f4..cb7d3c2674 100644 --- a/gtk/deprecated/gtkhandlebox.c +++ b/gtk/deprecated/gtkhandlebox.c @@ -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 float - * window) containing the child widget. A thin - * ghost 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 snap edge. + * 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. diff --git a/gtk/deprecated/gtkrc.c b/gtk/deprecated/gtkrc.c index d7eb201ea1..67c6c47156 100644 --- a/gtk/deprecated/gtkrc.c +++ b/gtk/deprecated/gtkrc.c @@ -89,7 +89,7 @@ * `--prefix` or `--sysconfdir` options when * configuring GTK+.) * - * The set of these default 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 "my-entry-class" to all - * widgets whose widget path matches the - * pattern "mywindow.*.GtkEntry". + * widgets whose “widget path” matches the + * “pattern” "mywindow.*.GtkEntry". * That is, all #GtkEntry widgets which are part of a #GtkWindow named * "mywindow". * @@ -127,7 +127,7 @@ * The "?" wildcard matches any character, while * "*" matches zero or more of any character. * The three types of matching are against the widget path, the - * class path and the class hierarchy. Both the + * “class path” and the class hierarchy. Both the * widget path and the class path consist of a "." * 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, diff --git a/gtk/gtkaccelgroup.c b/gtk/gtkaccelgroup.c index 0d11d30136..0745349a92 100644 --- a/gtk/gtkaccelgroup.c +++ b/gtk/gtkaccelgroup.c @@ -49,8 +49,8 @@ * automatically sets up the accelerators for your menus in the ui * manager's #GtkAccelGroup. * - * Note that accelerators are different from - * mnemonics. 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 diff --git a/gtk/gtkbuilder.c b/gtk/gtkbuilder.c index 3e07cbf6bc..a140b0da1a 100644 --- a/gtk/gtkbuilder.c +++ b/gtk/gtkbuilder.c @@ -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 - * GtkBuilder UI definitions or just - * UI definitions if the context is clear. + * “GtkBuilder UI definitions” or just + * “UI definitions” if the context is clear. * Do not confuse GtkBuilder UI Definitions with * GtkUIManager UI Definitions, which * are more limited in scope. It is common to use `.ui` diff --git a/gtk/gtkcellrenderer.c b/gtk/gtkcellrenderer.c index 5275a2e683..f7d623377f 100644 --- a/gtk/gtkcellrenderer.c +++ b/gtk/gtkcellrenderer.c @@ -53,9 +53,9 @@ * * Beyond merely rendering a cell, cell renderers can optionally * provide active user interface elements. A cell renderer can be - * activatable like #GtkCellRendererToggle, + * “activatable” like #GtkCellRendererToggle, * which toggles when it gets activated by a mouse click, or it can be - * editable 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 diff --git a/gtk/gtkicontheme.c b/gtk/gtkicontheme.c index 685cc02e1c..fd19e2ac8d 100644 --- a/gtk/gtkicontheme.c +++ b/gtk/gtkicontheme.c @@ -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 icon theme is selected + * depending on what “icon theme” is selected * by the user. The operation of icon themes on Linux and Unix * follows the Icon diff --git a/gtk/gtklabel.c b/gtk/gtklabel.c index 6ca271c5e2..b9fda264b4 100644 --- a/gtk/gtklabel.c +++ b/gtk/gtklabel.c @@ -92,7 +92,7 @@ * * ## Mnemonics * - * Labels may contain mnemonics. 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 "_File", to the diff --git a/gtk/gtkmain.c b/gtk/gtkmain.c index 44c2fa1140..91966634d4 100644 --- a/gtk/gtkmain.c +++ b/gtk/gtkmain.c @@ -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 main loop 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 - * signals. 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 - * callbacks. + * “callbacks”. * * When your callbacks are invoked, you would typically take some action - for * example, when an Open button is clicked you might display a diff --git a/gtk/gtkoverlay.c b/gtk/gtkoverlay.c index 084db86f67..eea5ac25f6 100644 --- a/gtk/gtkoverlay.c +++ b/gtk/gtkoverlay.c @@ -34,7 +34,7 @@ * @title: GtkOverlay * * GtkOverlay is a container which contains a single main child, on top - * of which it can place overlay 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 diff --git a/gtk/gtktextmark.c b/gtk/gtktextmark.c index e8fa205ca6..0c58498696 100644 --- a/gtk/gtktextmark.c +++ b/gtk/gtktextmark.c @@ -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 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. + * 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 diff --git a/gtk/gtkwidget.c b/gtk/gtkwidget.c index cff67a1903..0f2dca5900 100644 --- a/gtk/gtkwidget.c +++ b/gtk/gtkwidget.c @@ -238,8 +238,8 @@ * * ## Style Properties * - * #GtkWidget introduces style - * properties - 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 resource files. * 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 - * anchored 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. */