Commit 929a56e5 authored by Matthias Clasen's avatar Matthias Clasen
Browse files

Clean up lots of GTK+ -> GTK

Replace most remaining uses of GTK+ in the docs and
user-visible strings by GTK. Also remove some leftover
"Was added in 3.x" sentences from the docs.
parent 6ed1c181
Pipeline #213274 passed with stages
in 21 minutes and 6 seconds
......@@ -594,7 +594,7 @@ gdk_device_get_axis_use (GdkDevice *device,
* Returns the #GdkDisplay to which @device pertains.
*
* Returns: (transfer none): a #GdkDisplay. This memory is owned
* by GTK+, and must not be freed or unreffed.
* by GTK, and must not be freed or unreffed.
**/
GdkDisplay *
gdk_device_get_display (GdkDevice *device)
......
......@@ -1145,7 +1145,7 @@ _gdk_display_get_next_serial (GdkDisplay *display)
* Indicates to the GUI environment that the application has
* finished loading, using a given identifier.
*
* GTK+ will call this function automatically for #GtkWindow
* GTK will call this function automatically for #GtkWindow
* with custom startup-notification identifier unless
* gtk_window_set_auto_startup_notification() is called to
* disable that feature.
......
......@@ -301,9 +301,9 @@ typedef enum
* @GDK_CROSSING_NORMAL: crossing because of pointer motion.
* @GDK_CROSSING_GRAB: crossing because a grab is activated.
* @GDK_CROSSING_UNGRAB: crossing because a grab is deactivated.
* @GDK_CROSSING_GTK_GRAB: crossing because a GTK+ grab is activated.
* @GDK_CROSSING_GTK_UNGRAB: crossing because a GTK+ grab is deactivated.
* @GDK_CROSSING_STATE_CHANGED: crossing because a GTK+ widget changed
* @GDK_CROSSING_GTK_GRAB: crossing because a GTK grab is activated.
* @GDK_CROSSING_GTK_UNGRAB: crossing because a GTK grab is deactivated.
* @GDK_CROSSING_STATE_CHANGED: crossing because a GTK widget changed
* state (e.g. sensitivity).
* @GDK_CROSSING_TOUCH_BEGIN: crossing because a touch sequence has begun,
* this event is synthetic as the pointer might have not left the surface.
......
......@@ -30,13 +30,13 @@
* @Short_description: Using Pango in GDK
* @Title: Pango Interaction
*
* Pango is the text layout system used by GDK and GTK+. The functions
* Pango is the text layout system used by GDK and GTK. The functions
* and types in this section are used to obtain clip regions for
* #PangoLayouts, and to get #PangoContexts that can be used with
* GDK.
*
* Creating a #PangoLayout object is the first step in rendering text,
* and requires getting a handle to a #PangoContext. For GTK+ programs,
* and requires getting a handle to a #PangoContext. For GTK programs,
* you’ll usually want to use gtk_widget_get_pango_context(), or
* gtk_widget_create_pango_layout(). Once you have a #PangoLayout,
* you can set the text and attributes of it with Pango functions like
......
......@@ -525,7 +525,7 @@
[self setFrame:new_frame display:YES];
/* Let the resizing be handled by GTK+. */
/* Let the resizing be handled by GTK. */
if (g_main_context_pending (NULL))
g_main_context_iteration (NULL, FALSE);
......
......@@ -300,7 +300,7 @@ gdk_macos_keymap_update (GdkMacosKeymap *self)
}
}
/* Special-case shift-tab since GTK+ expects
/* Special-case shift-tab since GTK expects
* GDK_KEY_ISO_Left_Tab for that.
*/
if (found && p[j] == GDK_KEY_Tab && modifiers[j] == shiftKey)
......
......@@ -1795,7 +1795,7 @@ gdk_wayland_surface_create_xdg_toplevel (GdkSurface *surface)
app_id = g_get_prgname ();
if (app_id == NULL)
app_id = "GTK+ Application";
app_id = "GTK Application";
gdk_wayland_surface_set_application_id (surface, app_id);
......@@ -2587,7 +2587,7 @@ find_grab_input_seat (GdkSurface *surface,
GdkWaylandSurface *tmp_impl;
/* Use the device that was used for the grab as the device for
* the popup surface setup - so this relies on GTK+ taking the
* the popup surface setup - so this relies on GTK taking the
* grab before showing the popup surface.
*/
if (impl->grab_input_seat)
......@@ -2611,7 +2611,7 @@ should_be_mapped (GdkSurface *surface)
{
GdkWaylandSurface *impl = GDK_WAYLAND_SURFACE (surface);
/* Don't map crazy temp that GTK+ uses for internal X11 shenanigans. */
/* Don't map crazy temp that GTK uses for internal X11 shenanigans. */
if (GDK_IS_DRAG_SURFACE (surface) && surface->x < 0 && surface->y < 0)
return FALSE;
......
......@@ -24,9 +24,9 @@
*/
/*
GTK+ has two clipboards - normal clipboard and primary clipboard
GTK has two clipboards - normal clipboard and primary clipboard
Primary clipboard is only handled
internally by GTK+ (it's not portable to Windows).
internally by GTK (it's not portable to Windows).
("C:" means clipboard client (requestor), "S:" means clipboard server (provider))
("transmute" here means "change the format of some data"; this term is used here
......@@ -34,7 +34,7 @@ internally by GTK+ (it's not portable to Windows).
which are completely unrelated)
For Clipboard:
GTK+ calls one of the gdk_clipboard_set* () functions (either supplying
GTK calls one of the gdk_clipboard_set* () functions (either supplying
its own content provider, or giving a GTyped data for which GDK will
create a content provider automatically).
That function associates the content provider with the clipboard and calls
......@@ -53,12 +53,12 @@ No data is sent anywhere.
The content provider has a callback, which will be invoked every time
the data from this provider is needed.
GTK+ might also call gdk_clipboard_store_async(), which instructs
GTK might also call gdk_clipboard_store_async(), which instructs
the backend to put the data into the OS clipboard manager (if
supported and available) so that it remains available for other
processes after the clipboard owner terminates.
When something needs to be obtained from clipboard, GTK+ calls
When something needs to be obtained from clipboard, GTK calls
C: gdk_clipboard_read_async () -> gdk_clipboard_read_internal (),
providing it with a string-array of mime/types, which is internally
converted into a GdkContentFormats object.
......@@ -118,7 +118,7 @@ The thread remembers the fact that it has clipboard open, and does
not try to close & reopen it, unless that is strictly necessary.
The clipboard is closed after each queue processing run.
GTK+ calls one of the gdk_clipboard_set* () functions (either supplying
GTK calls one of the gdk_clipboard_set* () functions (either supplying
its own content provider, or giving a GTyped data for which GDK will
create a content provider automatically).
That function associates the content provider with the clipboard and calls
......@@ -145,7 +145,7 @@ No data is sent anywhere.
The content provider has a callback, which will be invoked every time
the data from this provider is needed.
GTK+ might also call gdk_clipboard_store_async(), which instructs
GTK might also call gdk_clipboard_store_async(), which instructs
the W32 backend to put the data into the OS clipboard manager by
sending WM_RENDERALLFORMATS to itself and then handling it normally.
......@@ -168,7 +168,7 @@ The cached remote formats are then mapped into GDK contentformats.
This map is separate from the one that maps supported GDK contentformats
to W32 formats for locally-claimed clipboards.
When something needs to be obtained from clipboard, GTK+ calls
When something needs to be obtained from clipboard, GTK calls
C: gdk_clipboard_read_async () -> gdk_clipboard_read_internal (),
providing it with a string-array of mime/types, which is internally
converted into a GdkContentFormats object.
......@@ -233,7 +233,7 @@ functions that read arbitrary GTypes (as long as they are serializable),
texts (strings) or textures (GdkPixbufs) this way.
If data must be stored on the clipboard, because the application is quitting,
GTK+ will call
GTK will call
S: gdk_clipboard_store_async()
on all the clipboards it owns. This creates multiple write stream (one for each
format being stored), each backed by a HGLOBAL memory object. Once all memory
......@@ -1572,7 +1572,7 @@ gdk_win32_clipdrop_init (GdkWin32Clipdrop *win32_clipdrop)
_gdk_atom_array_index (atoms, GDK_WIN32_ATOM_INDEX_JFIF) = g_intern_static_string ("JFIF");
_gdk_atom_array_index (atoms, GDK_WIN32_ATOM_INDEX_GIF) = g_intern_static_string ("GIF");
/* These are a bit unusual. It's here to allow GTK+ applications
/* These are a bit unusual. It's here to allow GTK applications
* to actually support CF_DIB and Shell ID List clipboard formats on their own,
* instead of allowing GDK to use them internally for interoperability.
*/
......@@ -1634,7 +1634,7 @@ gdk_win32_clipdrop_init (GdkWin32Clipdrop *win32_clipdrop)
win32_clipdrop->compatibility_w32formats = g_hash_table_new_full (NULL, NULL, NULL, (GDestroyNotify) g_array_unref);
/* GTK+ actually has more text formats, but it's unlikely that we'd
/* GTK actually has more text formats, but it's unlikely that we'd
* get anything other than UTF8_STRING these days.
* GTKTEXTBUFFERCONTENTS format can potentially be converted to
* W32-compatible rich text format, but that's too complex to address right now.
......
......@@ -57,7 +57,7 @@ static int debug_indent = 0;
*
* Adds an event filter to @window, allowing you to intercept messages
* before they reach GDK. This is a low-level operation and makes it
* easy to break GDK and/or GTK+, so you have to know what you're
* easy to break GDK and/or GTK, so you have to know what you're
* doing.
**/
void
......
......@@ -46,27 +46,27 @@
* the window.
*
* There's a mismatch between data types supported by W32 (W32 formats)
* and by GTK+ (GDK contentformats).
* and by GTK (GDK contentformats).
* To account for it the data is transmuted back and forth. There are two
* main points of transmutation:
* * GdkWin32HDATAOutputStream: transmutes GTK+ data to W32 data
* * GdkWin32Drop: transmutes W32 data to GTK+ data
* * GdkWin32HDATAOutputStream: transmutes GTK data to W32 data
* * GdkWin32Drop: transmutes W32 data to GTK data
*
* There are also two points where data formats are considered:
* * When source drag context is created, it gets a list of GDK contentformats
* that it supports, these are matched to the W32 formats they
* correspond to (possibly with transmutation). New W32 formats for
* GTK+-specific contentformats are also created here (see below).
* GTK-specific contentformats are also created here (see below).
* * When target drop context is created, it queries the IDataObject
* for the list of W32 formats it supports and matches these to
* corresponding GDK contentformats that it will be able to provide
* (possibly with transmutation) later. Missing GDK contentformats for
* W32-specific formats are also created here (see below).
*
* W32 formats are integers (CLIPFORMAT), while GTK+ contentformats
* W32 formats are integers (CLIPFORMAT), while GTK contentformats
* are mime/type strings, and cannot be used interchangeably.
*
* To accommodate advanced GTK+ applications the code allows them to
* To accommodate advanced GTK applications the code allows them to
* register drop targets that accept W32 data formats, and to register
* drag sources that provide W32 data formats. To do that they must
* register with the mime/type "application/x.windows.ZZZ", where
......@@ -77,36 +77,36 @@
* If such contentformat is accepted/provided, GDK will not try to
* transmute it to/from something else. Otherwise GDK will do the following
* transmutation:
* * If GTK+ application provides image/png, image/gif or image/jpeg,
* * If GTK application provides image/png, image/gif or image/jpeg,
* GDK will claim to also provide "PNG", "GIF" or "JFIF" respectively,
* and will pass these along verbatim.
* * If GTK+ application provides any GdkPixbuf-compatible contentformat,
* * If GTK application provides any GdkPixbuf-compatible contentformat,
* GDK will also offer "PNG" and CF_DIB W32 formats.
* * If GTK+ application provides text/plain;charset=utf8, GDK will also offer
* * If GTK application provides text/plain;charset=utf8, GDK will also offer
* CF_UNICODETEXT (UTF-16-encoded) and CF_TEXT (encoded with thread-
* and locale-dependent codepage), and will do the conversion when such
* data is requested.
* * If GTK+ application accepts image/png, image/gif or image/jpeg,
* * If GTK application accepts image/png, image/gif or image/jpeg,
* GDK will claim to also accept "PNG", "GIF" or "JFIF" respectively,
* and will pass these along verbatim.
* * If GTK+ application accepts image/bmp, GDK will
* * If GTK application accepts image/bmp, GDK will
* claim to accept CF_DIB W32 format, and will convert
* it, changing the header, when such data is provided.
* * If GTK+ application accepts text/plain;charset=utf8, GDK will
* * If GTK application accepts text/plain;charset=utf8, GDK will
* claim to accept CF_UNICODETEXT and CF_TEXT, and will do
* the conversion when such data is provided.
* * If GTK+ application accepts text/uri-list, GDK will
* * If GTK application accepts text/uri-list, GDK will
* claim to accept "Shell IDList Array", and will do the
* conversion when such data is provided.
*
* Currently the conversion from text/uri-list to "Shell IDList Array" is not
* implemented, so it's not possible to drag & drop files from GTK+
* applications to non-GTK+ applications the same way one can drag files
* implemented, so it's not possible to drag & drop files from GTK
* applications to non-GTK applications the same way one can drag files
* from Windows Explorer.
*
* To increase inter-GTK compatibility, GDK will register GTK+-specific
* To increase inter-GTK compatibility, GDK will register GTK-specific
* formats by their mime/types, as-is (i.e "text/plain;charset=utf-8", for example).
* That way two GTK+ applications can exchange data in their native formats
* That way two GTK applications can exchange data in their native formats
* (both well-known ones, such as text/plain;charset=utf8, and special,
* known only to specific applications). This will work just
* fine as long as both applications agree on what kind of data is stored
......@@ -118,7 +118,7 @@
* If more flexibility is needed, register one format that has some
* internal indicators of the kind of data it contains, then write the application
* in such a way that it requests the data and inspects its header before deciding
* whether to accept it or not. For details see GTK+ drag & drop documentation
* whether to accept it or not. For details see GTK drag & drop documentation
* on the "drag-motion" and "drag-data-received" signals.
*
* How managed DnD works:
......
......@@ -1007,7 +1007,7 @@ gdk_dropfiles_filter (GdkWin32Display *display,
/* Awful hack to recognize temp files corresponding to
* images dragged from Firefox... Open the file right here
* so that it is less likely that Firefox manages to delete
* it before the GTK+-using app (typically GIMP) has opened
* it before the GTK-using app (typically GIMP) has opened
* it.
*
* Not compiled in for now, because it means images dragged
......
......@@ -1422,13 +1422,13 @@ gdk_x11_drag_drag_motion (GdkDrag *drag,
if (protocol == GDK_DRAG_PROTO_XDND && drag_x11->version == 0)
{
/* This ugly hack is necessary since GTK+ doesn't know about
/* This ugly hack is necessary since GTK doesn't know about
* the XDND protocol version, and in particular doesn't know
* that gdk_drag_find_window() has the side-effect
* of setting drag_x11->version, and therefore sometimes call
* gdk_x11_drag_drag_motion() without a prior call to
* gdk_drag_find_window(). This happens, e.g.
* when GTK+ is proxying DND events to embedded windows.
* when GTK is proxying DND events to embedded windows.
*/
if (proxy_xid)
{
......@@ -1517,7 +1517,7 @@ gdk_x11_drag_drag_motion (GdkDrag *drag,
case GDK_DRAG_PROTO_ROOTWIN:
{
GdkContentFormats *formats = gdk_drag_get_formats (drag);
/* GTK+ traditionally has used application/x-rootwin-drop,
/* GTK traditionally has used application/x-rootwin-drop,
* but the XDND spec specifies x-rootwindow-drop.
*/
if (gdk_content_formats_contain_mime_type (formats, "application/x-rootwindow-drop") ||
......
......@@ -2845,14 +2845,14 @@ gdk_x11_surface_set_shadow_width (GdkSurface *surface,
* @surface: (type GdkX11Surface): a #GdkSurface
* @variant: the theme variant to export
*
* GTK+ applications can request a dark theme variant. In order to
* make other applications - namely window managers using GTK+ for
* themeing - aware of this choice, GTK+ uses this function to
* GTK applications can request a dark theme variant. In order to
* make other applications - namely window managers using GTK for
* themeing - aware of this choice, GTK uses this function to
* export the requested theme variant as _GTK_THEME_VARIANT property
* on toplevel surfaces.
*
* Note that this property is automatically updated by GTK+, so this
* function should only be used by applications which do not use GTK+
* Note that this property is automatically updated by GTK, so this
* function should only be used by applications which do not use GTK
* to create toplevel surfaces.
*/
void
......
......@@ -2460,10 +2460,10 @@ render_node_print (Printer *p,
*
* Serializes the @node for later deserialization via
* gsk_render_node_deserialize(). No guarantees are made about the format
* used other than that the same version of GTK+ will be able to deserialize
* used other than that the same version of GTK will be able to deserialize
* the result of a call to gsk_render_node_serialize() and
* gsk_render_node_deserialize() will correctly reject files it cannot open
* that were created with previous versions of GTK+.
* that were created with previous versions of GTK.
*
* The intended use of this functions is testing, benchmarking and debugging.
* The format is not meant as a permanent storage format.
......
......@@ -272,7 +272,7 @@ gtk_assistant_page_class_init (GtkAssistantPageClass *class)
* GtkAssistantPage:complete:
*
* Setting the "complete" property to %TRUE marks a page as
* complete (i.e.: all the required fields are filled out). GTK+ uses
* complete (i.e.: all the required fields are filled out). GTK uses
* this information to control the sensitivity of the navigation buttons.
*/
g_object_class_install_property (object_class,
......@@ -2042,7 +2042,7 @@ gtk_assistant_get_page_complete (GtkAssistant *assistant,
*
* Forces @assistant to recompute the buttons state.
*
* GTK+ automatically takes care of this in most situations,
* GTK automatically takes care of this in most situations,
* e.g. when the user goes to a different page, or when the
* visibility or completeness of a page changes.
*
......
......@@ -27,7 +27,7 @@
* parsing custom tags and constructing child objects.
*
* The GtkBuildable interface is implemented by all widgets and
* many of the non-widget objects that are provided by GTK+. The
* many of the non-widget objects that are provided by GTK. The
* main user of this interface is #GtkBuilder. There should be
* very little need for applications to call any of these functions directly.
*
......
......@@ -56,7 +56,7 @@ typedef struct _GtkBuilderClass GtkBuilderClass;
* @GTK_BUILDER_ERROR_INVALID_VALUE: #GtkBuilder couldn’t parse
* some attribute value.
* @GTK_BUILDER_ERROR_VERSION_MISMATCH: The input file requires a newer version
* of GTK+.
* of GTK.
* @GTK_BUILDER_ERROR_DUPLICATE_ID: An object id occurred twice.
* @GTK_BUILDER_ERROR_OBJECT_TYPE_REFUSED: A specified object type is of the same type or
* derived from the type of the composite class being extended with builder XML.
......
......@@ -39,7 +39,7 @@
*
* As outlined in
* [GtkWidget’s geometry management section][geometry-management],
* GTK+ uses a height-for-width
* 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
* size of an area for an arbitrary number of #GtkTreeModel rows.
......
......@@ -58,7 +58,7 @@
* ]|
*
* Furthermore for implementations of GtkCellLayout that use a #GtkCellArea
* to lay out cells (all GtkCellLayouts in GTK+ 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.
......
......@@ -242,7 +242,7 @@ gtk_cell_renderer_class_init (GtkCellRendererClass *class)
* See gtk_cell_editable_start_editing() for information on the lifecycle of
* the @editable and a way to do setup that doesn’t depend on the @renderer.
*
* Note that GTK+ doesn't guarantee that cell renderers will
* Note that GTK doesn't guarantee that cell renderers will
* continue to use the same kind of widget for editing in future
* releases, therefore you should check the type of @editable
* before doing any specific setup, as in the following example:
......
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