Since we have a convenience method to add actions let's allow to remove
them just as easily. This makes resource cleanup as simple as initially
adding the entries.
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.
Without a timeout, some lookup requests can go on forever, typically due
to bugs in underlying systems.
This can have particularly significant effects on the Happy Eyeballs
algorithm in `GSocketClient`, which relies on multiple name lookups as
its first step.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
Helps: #2866
This solves problems with validating untrusted inputs from D-Bus, where
invalid numbers of added and removed menu entries, and positions, could
be specified.
Original patch from
https://bugzilla.gnome.org/show_bug.cgi?id=728733#c7, tweaked by Philip
Withnall to add a few code comments and make
`G_MENU_EXPORTER_MAX_SECTION_SIZE` public so callers can check their
inputs against it if they want. Also tweaked to use `g_warning()` instead
of the nonexistent `g_dbus_warning()`.
Fixes: #861
Some applications (eg., gnome-photos) really want a large thumbnail,
if one can be created. Simply falling back to a smaller one (probably
created by an old nautilus), without giving the application a chance
to create a bigger thumbnail, is undesirable because they will appear
fuzzy.
Therefore, at separate attribute sets for all the thumbnail sizes
that are supported in the spec: normal/large/x-large/xx-large.
The old attribute will now return by default the biggest available, as
it used to be, but also including the x-large and xx-large cases.
Co-Authored-by: Marco Trevisan <mail@3v1n0.net>
Fixes: #621
This reverts commit 19353017a7.
The freedesktop SDK, which is used by gnome-build-meta, only has Meson
0.63. Bumping GLib’s Meson dependency to 0.64 means that, at the moment,
GLib is not buildable in gnome-build-meta and hence can’t be tested in
nightly pipelines against other projects, etc.
That’s bad for testing GLib.
It’s arguably bad that we’re restricted to using an older version of
Meson than shipped by Debian Testing, but that’s a separate discussion
to be had.
Revert the Meson 0.64 dependency until the freedesktop SDK ships Meson ≥
0.64. This also means reverting the simplifications to use of
`gnome.mkenum_simple()`.
See https://gitlab.gnome.org/GNOME/glib/-/merge_requests/3077#note_1601064
Because Meson complains about using `configure_file(copy: true)`.
Includes improvements by Xavier Claessens.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
Similar to g_source_set_static_name, this avoids
strdup overhead for debug-only information in
possibly hot code paths.
We also add a macro wrapper for g_task_set_name that
uses __builtin_constant_p to decide whether to use
g_task_set_name or g_task_set_static_name.
There is currently no `dllimport` attribute on any of our function,
which prevents MSVC to optimize function calls.
To fix that issue, we need to redeclare all our visibility macros for
each of our libraries, because when compiling e.g. GIO code, we need
dllimport in GLIB headers and dllexport in GIO headers. That means they
cannot use the same GLIB_AVAILABLE_* macro.
Since that's a lot of boilerplate to copy/paste after each version bump,
this MR generate all those macros using a python script.
Also simplify the meson side by using `gnu_symbol_visibility : 'hidden'`
keyword argument instead of passing the cflag manually.
This leaves only API index to add manually into glib-docs.xml when
bumping GLib version. That file cannot be generated because Meson does
not allow passing a buit file to gnome.gtkdoc()'s main_xml kwarg
unfortunately.
While it's possible to create a directory synchronously via
g_dir_make_tmp(), there's no such API that performs it asynchronously.
So implement it using GFile, using a thread to perform such task.
Rather than carrying the copylib around inside GLib, which is a pain to
synchronise and affects our code coverage statistics.
This requires updating the CI images to cache the new subproject,
including updating the `cache-subprojects.sh` script to pull in git
submodules.
It also requires adding `gioenumtypes_dep` to be added to the
dependencies list of `libgio`, since it needs to be build before GVDB as
it’s pulled in by the GIO headers which GVDB includes.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
Helps: #2603
The interface was ready for this API but it was not provided.
So implement this, using a thread that calls the sync API for now.
Add tests.
Helps with: GNOME/glib#157
libgamin was last released in 2007 and is dead
[upstream](https://gitlab.gnome.org/Archive/gamin). Distributions may
still ship it (although Fedora no longer does), but we want people to
use inotify on Linux since it’s actively supported.
BSDs use kqueue. Windows uses win32filemonitor.
FAM might still be used on some commercial Unix distributions, but there
are no contributors from those distributions, and certainly no CI for
them to prevent regressions.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
Fixes: #2614
It used to exist on Solaris, but GLib’s support for it was mostly
removed in 2015 in commit 21ab660cf8.
Remove the final few references.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
This allows the controller to explicitly be removed from the bus, in a
way that allows the caller to synchronise with it and know that all
other references to the controller should have been dropped (i.e. after
this method returns, there should be no in-flight D-Bus calls still
holding a reference to the object).
This is needed to be able to guarantee finalisation of the controller in
unit tests (and comparable real-world situations).
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
Helps: #1190
The resources data is generated for both GCC and MSVC toolchains, even
though we know beforehand which toolchain we're going to compile it for.
By dropping the data duplication we make the generated resources file
faster to compile, especially when dealing with large embedded data,
instead of relying on the C pre-processor to walk the whole file and
discard the branch we're not using.
If `GDebugControllerDBus` remains as the only, or default,
implementation of `GDebugController`, `dup_default()` cannot work.
`GDebugControllerDBus` requires a `GDBusConnection` at construction
time, which the `GIOModule` construction code can’t provide it.
Either we use a default D-Bus connection (but which one? and how would
it be changed by the user later if it was the wrong one?), or delegate
singleton handling of the `GDebugController` to the user.
The latter approach seems more flexible.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
Helps: #1190
This is intended to provide a uniform interface for controlling whether
the debug output from an application (or service) is emitted, typically
to journald, but actually to wherever the application chooses to output
it.
The main implementation of `GDebugController` is `GDebugControllerDBus`,
which is intended to be used on Linux. Other implementations may be
added in future for other platforms, or larger applications may want to
provide their own implementation which integrates with their ecosystem.
The `GDebugControllerDBus` implementation exposes a D-Bus interface at
`/org/gtk/Debugging` with a method to enable or disable debug
output at runtime.
This could be used by external harnesses, such as GNOME Builder or
systemd, to give a uniform way to get debug output from an application.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
Fixes: #1190
On !UNIX, return an error for send_fd() & receive_fd().
(the unixfdmessage unit is not compiled on !UNIX)
The header is installed under the common GIO include directory.
Ensure G_TYPE_UNIX_CONNECTION is registered on all platforms.
Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com>
The header is now also installed under the common GIO include directory.
Sorry if it breaks any build, you had to use the correct header path.
Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com>
Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com>
Move the header under the common GIO include directory.
Sorry if it breaks any build, you had to use the correct header path.
Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com>