luc14n0/glib
1
0
Fork 0
mirror of https://gitlab.gnome.org/GNOME/glib.git synced 2025-02-02 17:26:17 +01:00
Code Issues Packages Projects Releases Wiki Activity

Rename GTK+ to GTK (mostly comments and documentation)

Browse Source 
GTK lost it's '+' suffix back in 2019, according to
<https://mail.gnome.org/archives/gtk-devel-list/2019-February/msg00000.html>

This commit can be re-generated with:

    git grep -l GTK+ \
    | grep -v -e ^NEWS -e ^glib/tests/collate.c \
    | xargs sed -i 's/GTK+/GTK/g'

Most of the changes are in comments and documentation.
This commit is contained in:
Arnaud Rebillout 2023-05-10 10:11:24 +07:00
parent 20964ad4ab
commit f722f11e57
28 changed files with 60 additions and 60 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

6
README.win32.md
View File

@ -9,7 +9,7 @@ warned.
# General
For prebuilt binaries (DLLs and EXEs) and developer packages (headers,
import libraries) of GLib, Pango, GTK+ etc for Windows, go to
import libraries) of GLib, Pango, GTK etc for Windows, go to
https://www.gtk.org/docs/installations/windows/ . They are for "native"
Windows meaning they use the Win32 API and Microsoft C runtime library
only. No POSIX (Unix) emulation layer like Cygwin is involved.
@ -59,9 +59,9 @@ MinGW](https://mingwpy.github.io/ucrt.html) too.
GLib is not actively tested with the static versions of the UCRT, but if you
need to use those, patches are welcome.
# Building software that use GLib or GTK+
# Building software that use GLib or GTK
Building software that just *uses* GLib or GTK+ also require to have
Building software that just *uses* GLib or GTK also require to have
the right compiler set up the right way. If you intend to use MinGW-GCC,
follow the relevant instructions below in that case, too.

4
docs/reference/gio/overview.xml
View File

@ -154,7 +154,7 @@
</para>
<figure id="gvfs-overview">
<title>GIO in the GTK+ library stack</title>
<title>GIO in the GTK library stack</title>
<graphic fileref="gvfs-overview.png" format="PNG"></graphic>
</figure>
@ -166,7 +166,7 @@
</para>
<para>
One of the big advantages of putting the VFS in the GLib layer
is that GTK+ can directly use it, e.g. in the filechooser.
is that GTK can directly use it, e.g. in the filechooser.
</para>
</chapter>

2
docs/reference/glib/building.xml
View File

@ -49,7 +49,7 @@
aliasing and cannot be guaranteed to work.
</para>
<para>
The GTK+ documentation contains
The GTK documentation contains
<ulink url="https://developer.gnome.org/gtk3/stable/gtk-building.html">further details</ulink>
about the build process and ways to influence it.
</para>

2
docs/reference/gobject/tut_gobject.xml
View File

@ -19,7 +19,7 @@
<listitem><para>Generic per-object properties with set/get function pairs</para></listitem>
<listitem><para>Easy use of signals</para></listitem>
</itemizedlist>
All the GNOME libraries which use the GLib type system (like GTK+ and GStreamer)
All the GNOME libraries which use the GLib type system (like GTK and GStreamer)
inherit from <link linkend="GObject"><type>GObject</type></link> which is why it is important to understand
the details of how it works.
</para>

12
docs/reference/gobject/tut_gsignal.xml
View File

@ -10,7 +10,7 @@
<para>
Closures are central to the concept of asynchronous signal delivery
which is widely used throughout GTK+ and GNOME applications. A closure is an
which is widely used throughout GTK and GNOME applications. A closure is an
abstraction, a generic representation of a callback. It is a small structure
which contains three objects:
<itemizedlist>
@ -37,9 +37,9 @@ return_type function_callback (… , gpointer user_data);
<footnote><para>
In practice, closures sit at the boundary of language runtimes: if you are
writing Python code and one of your Python callbacks receives a signal from
a GTK+ widget, the C code in GTK+ needs to execute your Python
code. The closure invoked by the GTK+ object invokes the Python callback:
it behaves as a normal C object for GTK+ and as a normal Python object for
a GTK widget, the C code in GTK needs to execute your Python
code. The closure invoked by the GTK object invokes the Python callback:
it behaves as a normal C object for GTK and as a normal Python object for
Python code.
</para></footnote>
The GObject library provides a simple <link linkend="GCClosure"><type>GCClosure</type></link> type which
@ -179,8 +179,8 @@ g_cclosure_marshal_VOID__INT (GClosure *closure,
<para>
GObject's signals have nothing to do with standard UNIX signals: they connect
arbitrary application-specific events with any number of listeners.
For example, in GTK+, every user event (keystroke or mouse move) is received
from the windowing system and generates a GTK+ event in the form of a signal emission
For example, in GTK, every user event (keystroke or mouse move) is received
from the windowing system and generates a GTK event in the form of a signal emission
on the widget object instance.
</para>

4
docs/reference/gobject/tut_howto.xml
View File

@ -17,7 +17,7 @@
<para>
This chapter focuses on the implementation of a subtype of GObject, for
example to create a custom class hierarchy, or to subclass a GTK+ widget.
example to create a custom class hierarchy, or to subclass a GTK widget.
</para>
<para>
@ -55,7 +55,7 @@
<filename>viewer_file.c</filename>.</para></listitem>
<listitem><para>Do not separate the prefix from the typename:
<filename>viewerfile.h</filename> and <filename>viewerfile.c</filename>.
(this is the convention used by GTK+)</para></listitem>
(this is the convention used by GTK)</para></listitem>
</itemizedlist>
Some people like the first two solutions better: it makes reading file
names easier for those with poor eyesight.

2
docs/reference/gobject/tut_intro.xml
View File

@ -6,7 +6,7 @@
<title>Background</title>
<para>
GObject, and its lower-level type system, GType, are used by GTK+ and most GNOME libraries to
GObject, and its lower-level type system, GType, are used by GTK and most GNOME libraries to
provide:
<itemizedlist>
<listitem><para>object-oriented C-based APIs and</para></listitem>

4
docs/reference/gobject/tut_tools.xml
View File

@ -62,7 +62,7 @@
Yet another tool that you may find helpful when working with
GObjects is <ulink
url="http://sourceforge.net/projects/g-inspector">G-Inspector</ulink>. It
is able to display GLib/GTK+ objects and their properties.
is able to display GLib/GTK objects and their properties.
</para>
</chapter>
@ -90,7 +90,7 @@ break g_object_unref if _object == 0xcafebabe
<chapter id="tools-gtkdoc">
<title>Writing API docs</title>
<para>The API documentation for most of the GLib, GObject, GTK+ and GNOME
<para>The API documentation for most of the GLib, GObject, GTK and GNOME
libraries is built with a combination of complex tools. Typically, the part of
the documentation which describes the behavior of each function is extracted
from the specially-formatted source code comments by a tool named gtk-doc which

2
docs/toolchain-requirements.md
View File

@ -139,7 +139,7 @@ Selected C99 features
_Hard requirement._
Starting with GLib 2.52 and GTK+ 3.90, we will be using the following C99
Starting with GLib 2.52 and GTK 3.90, we will be using the following C99
features where appropriate:
* Compound literals

2
gio/gapplication.c
View File

@ -2230,7 +2230,7 @@ g_application_register (GApplication *application,
* Increases the use count of @application.
*
* Use this function to indicate that the application has a reason to
* continue to run. For example, g_application_hold() is called by GTK+
* continue to run. For example, g_application_hold() is called by GTK
* when a toplevel window is on the screen.
*
* To cancel the hold, call g_application_release().

2
gio/gunixmounts.c
View File

@ -3036,7 +3036,7 @@ g_unix_mount_point_guess_can_eject (GUnixMountPoint *mount_point)
/* Utility functions {{{1 */
#ifdef HAVE_MNTENT_H
/* borrowed from gtk/gtkfilesystemunix.c in GTK+ on 02/23/2006 */
/* borrowed from gtk/gtkfilesystemunix.c in GTK on 02/23/2006 */
static void
_canonicalize_filename (gchar *filename)
{

18
gio/tests/desktop-files/usr/applications/glade.desktop
View File

@ -27,15 +27,15 @@ X-GNOME-FullName[en_GB]=Glade Interface Designer
X-GNOME-FullName[eo]=Uzantointerfaca dizajnilo Glado
X-GNOME-FullName[pt]=Designer de Interfaces Glade
X-GNOME-FullName[pt_BR]=Construtor de interfaces Glade
Comment=Create or open user interface designs for GTK+ applications
Comment[ca]=Creeu o obriu dissenys d'interfície d'usuari per a aplicacions GTK+
Comment[ca@valencia]=Creeu o obriu dissenys d'interfície d'usuari per a aplicacions GTK+
Comment[en@shaw]=𐑒𐑮𐑦𐑱𐑑 𐑹 𐑴𐑐𐑩𐑯 𐑿𐑟𐑼 𐑦𐑯𐑑𐑼𐑓𐑱𐑕 𐑛𐑩𐑟𐑲𐑯𐑟 𐑓𐑹 GTK+ 𐑩𐑐𐑤𐑦𐑒𐑱𐑕𐑩𐑯𐑟
Comment[en_CA]=Create or open user interface designs for GTK+ applications
Comment[en_GB]=Create or open user interface designs for GTK+ applications
Comment[eo]=Krei aŭ malfermi uzantointerfacan dizajnon por aplikaĵoj de GTK+
Comment[pt]=Criar ou abrir um desenho de interface de utilizador para aplicações GTK+
Comment[pt_BR]=Crie ou abra projetos de interface com o usuário para aplicativos GTK+
Comment=Create or open user interface designs for GTK applications
Comment[ca]=Creeu o obriu dissenys d'interfície d'usuari per a aplicacions GTK
Comment[ca@valencia]=Creeu o obriu dissenys d'interfície d'usuari per a aplicacions GTK
Comment[en@shaw]=𐑒𐑮𐑦𐑱𐑑 𐑹 𐑴𐑐𐑩𐑯 𐑿𐑟𐑼 𐑦𐑯𐑑𐑼𐑓𐑱𐑕 𐑛𐑩𐑟𐑲𐑯𐑟 𐑓𐑹 GTK 𐑩𐑐𐑤𐑦𐑒𐑱𐑕𐑩𐑯𐑟
Comment[en_CA]=Create or open user interface designs for GTK applications
Comment[en_GB]=Create or open user interface designs for GTK applications
Comment[eo]=Krei aŭ malfermi uzantointerfacan dizajnon por aplikaĵoj de GTK
Comment[pt]=Criar ou abrir um desenho de interface de utilizador para aplicações GTK
Comment[pt_BR]=Crie ou abra projetos de interface com o usuário para aplicativos GTK
Keywords=GUI designer;user interface;ui builder;
Keywords[ca]=dissenyador d'interfícies d'usuari gràfiques;interfície d'usuari;constructor d'interfícies d'usuari;
Keywords[ca@valencia]=dissenyador d'interfícies d'usuari gràfiques;interfície d'usuari;constructor d'interfícies d'usuari;

2
glib.doap
View File

@ -10,7 +10,7 @@
<shortdesc xml:lang="en">Low level core library</shortdesc>
<description xml:lang="en">GLib is the low-level core library that forms the basis for projects such as GTK+ and GNOME. It provides data structure handling for C, portability wrappers, and interfaces for such runtime functionality as an event loop, threads, dynamic loading, and an object system.</description>
<description xml:lang="en">GLib is the low-level core library that forms the basis for projects such as GTK and GNOME. It provides data structure handling for C, portability wrappers, and interfaces for such runtime functionality as an event loop, threads, dynamic loading, and an object system.</description>
<homepage rdf:resource="http://www.gtk.org" />
<license rdf:resource="http://usefulinc.com/doap/licenses/lgpl" />

2
glib/docs.c
View File

@ -1068,7 +1068,7 @@
* @title: Type Conversion Macros
* @short_description: portably storing integers in pointer variables
*
* Many times GLib, GTK+, and other libraries allow you to pass "user
* Many times GLib, GTK, and other libraries allow you to pass "user
* data" to a callback, in the form of a void pointer. From time to time
* you want to pass an integer instead of a pointer. You could allocate
* an integer, with something like:

2
glib/gconvert.c
View File

@ -85,7 +85,7 @@
* Character: P r e s e n t a c i ó n . s x i
* Hex code: 50 72 65 73 65 6e 74 61 63 69 c3 b3 6e 2e 73 78 69
* ]|
* Glib uses UTF-8 for its strings, and GUI toolkits like GTK+ that use
* Glib uses UTF-8 for its strings, and GUI toolkits like GTK that use
* GLib do the same thing. If you get a file name from the file system,
* for example, from readdir() or from g_dir_read_name(), and you wish
* to display the file name to the user, you will need to convert it

2
glib/gerror.c
View File

@ -53,7 +53,7 @@
* These two kinds of errors are fundamentally different: runtime errors
* should be handled or reported to the user, programming errors should
* be eliminated by fixing the bug in the program. This is why most
* functions in GLib and GTK+ do not use the #GError facility.
* functions in GLib and GTK do not use the #GError facility.
*
* Functions that can fail take a return location for a #GError as their
* last argument. On error, a new #GError instance will be allocated and

6
glib/ggettext.c
View File

@ -362,12 +362,12 @@ _g_dgettext_should_translate (void)
* translations for the current locale.
*
* The advantage of using this function over dgettext() proper is that
* libraries using this function (like GTK+) will not use translations
* libraries using this function (like GTK) will not use translations
* if the application using the library does not have translations for
* the current locale. This results in a consistent English-only
* interface instead of one having partial translations. For this
* feature to work, the call to textdomain() and setlocale() should
* precede any g_dgettext() invocations. For GTK+, it means calling
* precede any g_dgettext() invocations. For GTK, it means calling
* textdomain() before gtk_init or its variants.
*
* This function disables translations if and only if upon its first
@ -385,7 +385,7 @@ _g_dgettext_should_translate (void)
*
* Note that this behavior may not be desired for example if an application
* has its untranslated messages in a language other than English. In those
* cases the application should call textdomain() after initializing GTK+.
* cases the application should call textdomain() after initializing GTK.
*
* Applications should normally not use this function directly,
* but use the _() macro for translations.

2
glib/glib-init.c
View File

@ -220,7 +220,7 @@ G_STATIC_ASSERT (sizeof (int) == sizeof (gint32));
*
* Parses a string containing debugging options
* into a %guint containing bit flags. This is used
* within GDK and GTK+ to parse the debug options passed on the
* within GDK and GTK to parse the debug options passed on the
* command line or through environment variables.
*
* If @string is equal to "all", all flags are set. Any flags

8
glib/gmain.c
View File

@ -133,7 +133,7 @@
* @short_description: manages all available sources of events
*
* The main event loop manages all the available sources of events for
* GLib and GTK+ applications. These events can come from any number of
* GLib and GTK applications. These events can come from any number of
* different types of sources such as file descriptors (plain files,
* pipes or sockets) and timeouts. New types of event sources can also
* be added using g_source_attach().
@ -165,12 +165,12 @@
* exit the main loop, and g_main_loop_run() returns.
*
* It is possible to create new instances of #GMainLoop recursively.
* This is often used in GTK+ applications when showing modal dialog
* This is often used in GTK applications when showing modal dialog
* boxes. Note that event sources are associated with a particular
* #GMainContext, and will be checked and dispatched for all main
* loops associated with that GMainContext.
*
* GTK+ contains wrappers of some of these functions, e.g. gtk_main(),
* GTK contains wrappers of some of these functions, e.g. gtk_main(),
* gtk_main_quit() and gtk_events_pending().
*
* ## Creating new source types
@ -2197,7 +2197,7 @@ g_source_set_name_full (GSource *source,
*
* The source name should describe in a human-readable way
* what the source does. For example, "X11 event queue"
* or "GTK+ repaint idle handler" or whatever it is.
* or "GTK repaint idle handler" or whatever it is.
*
* It is permitted to call this function multiple times, but is not
* recommended due to the potential performance impact. For example,

8
glib/gmain.h
View File

@ -73,7 +73,7 @@ typedef struct _GMainContext GMainContext;
* GMainLoop:
*
* The `GMainLoop` struct is an opaque data type
* representing the main event loop of a GLib or GTK+ application.
* representing the main event loop of a GLib or GTK application.
*/
typedef struct _GMainLoop GMainLoop;
@ -324,7 +324,7 @@ struct _GSourceFuncs
*
* Use this for high priority event sources.
*
* It is not used within GLib or GTK+.
* It is not used within GLib or GTK.
*/
#define G_PRIORITY_HIGH -100
@ -344,7 +344,7 @@ struct _GSourceFuncs
*
* Use this for high priority idle functions.
*
* GTK+ uses %G_PRIORITY_HIGH_IDLE + 10 for resizing operations,
* GTK uses %G_PRIORITY_HIGH_IDLE + 10 for resizing operations,
* and %G_PRIORITY_HIGH_IDLE + 20 for redrawing operations. (This is
* done to ensure that any pending resizes are processed before any
* pending redraws, so that widgets are not redrawn twice unnecessarily.)
@ -366,7 +366,7 @@ struct _GSourceFuncs
*
* Use this for very low priority background tasks.
*
* It is not used within GLib or GTK+.
* It is not used within GLib or GTK.
*/
#define G_PRIORITY_LOW 300

8
glib/gmessages.c
View File

@ -241,7 +241,7 @@
* not advisable, as it cannot be filtered against using the `G_MESSAGES_DEBUG`
* environment variable.
*
* For example, GTK+ uses this in its `Makefile.am`:
* For example, GTK uses this in its `Makefile.am`:
* |[
* AM_CPPFLAGS = -DG_LOG_DOMAIN=\"Gtk\"
* ]|
@ -831,7 +831,7 @@ g_log_set_fatal_mask (const gchar *log_domain,
* | G_LOG_FLAG_RECURSION, my_log_handler, NULL);
* ]|
*
* This example adds a log handler for all critical messages from GTK+:
* This example adds a log handler for all critical messages from GTK:
*
* |[<!-- language="C" -->
* g_log_set_handler ("Gtk", G_LOG_LEVEL_CRITICAL | G_LOG_FLAG_FATAL
@ -3295,7 +3295,7 @@ g_log_default_handler (const gchar *log_domain,
* Any messages passed to g_print() will be output via
* the new handler. The default handler outputs
* the encoded message to stdout. By providing your own handler
* you can redirect the output, to a GTK+ widget or a
* you can redirect the output, to a GTK widget or a
* log file for example.
*
* Since 2.76 this functions always returns a valid
@ -3424,7 +3424,7 @@ g_print (const gchar *format,
* Any messages passed to g_printerr() will be output via
* the new handler. The default handler outputs the encoded
* message to stderr. By providing your own handler you can
* redirect the output, to a GTK+ widget or a log file for
* redirect the output, to a GTK widget or a log file for
* example.
*
* Since 2.76 this functions always returns a valid

2
glib/goption.c
View File

@ -65,7 +65,7 @@
* Help Options:
* -h, --help Show help options
* --help-all Show all help options
* --help-gtk Show GTK+ Options
* --help-gtk Show GTK Options
*
* Application Options:
* -r, --repeats=N Average over N repetitions

2
glib/gquark.c
View File

@ -246,7 +246,7 @@ g_quark_from_string (const gchar *string)
* with statically allocated strings in the main program, but not with
* statically allocated memory in dynamically loaded modules, if you
* expect to ever unload the module again (e.g. do not use this
* function in GTK+ theme engines).
* function in GTK theme engines).
*
* This function must not be used before library constructors have finished
* running. In particular, this means it cannot be used to initialize global

2
glib/gtypes.h
View File

@ -165,7 +165,7 @@ typedef gpointer (*GCopyFunc) (gconstpointer src,
*
* Declares a type of function which takes an arbitrary
* data pointer argument and has no return value. It is
* not currently used in GLib or GTK+.
* not currently used in GLib or GTK.
*/
typedef void (*GFreeFunc) (gpointer data);

2
glib/gutf8.c
View File

@ -1678,7 +1678,7 @@ fast_validate_len (const char *str,
* Note that g_utf8_validate() returns %FALSE if @max_len is
* positive and any of the @max_len bytes are nul.
*
* Returns %TRUE if all of @str was valid. Many GLib and GTK+
* Returns %TRUE if all of @str was valid. Many GLib and GTK
* routines require valid UTF-8 as input; so data read from a file
* or the network should be checked with g_utf8_validate() before
* doing anything else with it.

6
glib/gutils.c
View File

@ -1138,7 +1138,7 @@ static const gchar *g_prgname = NULL; /* always a quark */
* in contrast to g_get_application_name().
*
* If you are using #GApplication the program name is set in
* g_application_run(). In case of GDK or GTK+ it is set in
* g_application_run(). In case of GDK or GTK it is set in
* gdk_init(), which is called by gtk_init() and the
* #GtkApplication::startup handler. The program name is found by
* taking the last component of @argv[0].
@ -1167,7 +1167,7 @@ g_get_prgname (void)
* in contrast to g_set_application_name().
*
* If you are using #GApplication the program name is set in
* g_application_run(). In case of GDK or GTK+ it is set in
* g_application_run(). In case of GDK or GTK it is set in
* gdk_init(), which is called by gtk_init() and the
* #GtkApplication::startup handler. The program name is found by
* taking the last component of @argv[0].
@ -2584,7 +2584,7 @@ g_win32_get_system_data_dirs_for_module_real (void (*address_of_function)(void))
/* Using the above subfolders of Documents and Settings perhaps
* makes sense from a Windows perspective.
*
* But looking at the actual use cases of this function in GTK+
* But looking at the actual use cases of this function in GTK
* and GNOME software, what we really want is the "share"
* subdirectory of the installation directory for the package
* our caller is a part of.

4
glib/gwin32.c
View File

@ -123,8 +123,8 @@ g_win32_getlocale (void)
const gchar *script = NULL;
/* Let the user override the system settings through environment
* variables, as on POSIX systems. Note that in GTK+ applications
* since GTK+ 2.10.7 setting either LC_ALL or LANG also sets the
* variables, as on POSIX systems. Note that in GTK applications
* since GTK 2.10.7 setting either LC_ALL or LANG also sets the
* Win32 locale and C library locale through code in gtkmain.c.
*/
if (((ev = g_getenv ("LC_ALL")) != NULL && ev[0] != '\0')

2
gobject/gobject.c
View File

@ -44,7 +44,7 @@
* @see_also: #GParamSpecObject, g_param_spec_object()
*
* GObject is the fundamental type providing the common attributes and
* methods for all object types in GTK+, Pango and other libraries
* methods for all object types in GTK, Pango and other libraries
* based on GObject. The GObject class provides methods for object
* construction and destruction, property access methods, and signal
* support. Signals are described in detail [here][gobject-Signals].