Much like GBindingGroup, the GSignalGroup object allows you to connect many
signal connections for an object and connect/disconnect/block/unblock them
as a group.
This is useful when using many connections on an object to ensure that they
are properly removed when changing state or disposing a third-party
object.
This has been used for years in various GNOME projects and makes sense to
have upstream instead of multiple copies.
Originally, GBindingGroup started with Builder as a way to simplify all
of the third-degree object bindings necessary around Model-Controller
objects such as TextBuffer/TextView.
Over time, it has grown to be useful in a number of scenarios outside
of Builder and has been copied into a number of projects such as GNOME
Text Editor, GtkSourceView, libdazzle, and more.
It makes sense at this point to unify on a single implementation and
include that upstream in GObject directly alongside GBinding.
On Windows, dbus is launched by spawning the gdbus.exe executable on
demand from the gio module. When linked dynamically, the executable
path is guessed relatively to the gio DLL path. But when linked
statically, the only reference path available is the current
executable path. In this case, gdbus.exe is not necessarily in the same
folder as the current executable.
This patch solves the issue using the same algorithm as the one used
with process spawning in glib core source code two commits above.
On Windows, process spawning needs an external helper exe which is found
relatively to the glib DLL file. If glib has been built statically this
file doesn't exist anymore and reference path is not the DLL path
anymore but the current executable path.
This patch searches for the helper exe taking as starting point the
current executable path, relative 'bin', 'lib', 'glib' and 'gio' folders
and then gets one level up until the root path. If this search doesn't
give result then the helper exe is searched using the PATH variable.
Fix a possibility of returning a relative path, in case PATH contains
a relative path. According to the doc, the function should return an
absolute path.
Signed-off-by: Christoph Niethammer <christoph.niethammer@gmail.com>
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
This is an API analogue of the G_MESSAGES_DEBUG environment variable. It
is intended to be exposed outside applications (for example, as a D-Bus
interface — see follow-up commits) so that there is a uniform interface
for controlling the debug output of an application.
Helps: #1190
As with the previous commit, this isn’t needed for GLib’s tests to work
correctly, but is probably needed in other projects which might be
tempted to copy and paste the Meson tooling from GLib.
Inspired by https://gitlab.gnome.org/GNOME/gtk/-/merge_requests/4330
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
This isn’t needed to make the tests any better (it doesn’t really affect
them), but is probably needed for anyone who copies this Meson code in
order to add `glib-compile-resources` support to their project. It’s
pretty unlikely that someone would want to compile *and export* a
resource from a shared library.
Inspired by https://gitlab.gnome.org/GNOME/gtk/-/merge_requests/4334
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
Credentials are often used to check peer processes details.
With AF_UNIX sockets on Windows, SIO_AF_UNIX_GETPEERPID can
be used to retrive the peer PID.
We will probably introduce more advanced mechanisms later on, though,
but I am not a Windows API expert.
Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com>
