* Remove an unneeded field from LaunchUrisData and add annotations
* Rename local GError* variables to local_error
* Use g_set_object
* Fix indentation
...of the application if many URI's are provided. This is important to note
because the GAppLaunchContext signals may be emitted multiple times during
a single launch operation.
We cannot cancel a spawn operation, but sometimes we have to
spawn the target application mutiple times (e.g. in case the
target app only supports one URI in its command-line, but we
were given multiple URI's), in that case continuously check
the cancellation status before attempting any spawn operation
First, there's no reason not to use the new `epoll_create1` system call,
which quickly obsoleted `epoll_create` which has an obsolete and
unused size argument.
But more specifically, it offers `EPOLL_CLOEXEC` which we want
to use for general hygeine - there's no reason to potentially
leak this file descriptor to forked processes.
(GLib itself carefully closes file descriptors when forking child
processes, but it may be linked with other software that doesn't;
notably in my case for example the Rust standard library does not
do this and hence relies more on the application code using
`O_CLOEXEC` and variants)
This is just a drive-by fix; I saw the system call when I was using
`strace` to debug something else in rpm-ostree.
GParamSpec nicks and blurbs are effectively a deprecated feature,
or at least unused by most libraries these days. Since a number
of C libraries (i.e. GTK4) have started to null these out, annotate
them as `(nullable)` so bindings can do the same.
Closes#2719
For all the memory allocator APIS, document
that they terminate the program on failure.
This was so far only mentioned in the long description,
and in the docs for g_try_malloc(). And with gi-docgen
style docs, the long description is going away.
This utility function will be called by both launch_uris and
launch_uris_async, passing a from_task parameter respectively
as NULL and non-NULL. The from_task parameter will be needed
to know whether GAppLaunchContext signals should be emitted
directly (from_task == NULL) or scheduled for emission on the
main thread (from_task != NULL).
All of these warnings indicate programmer error, so critical is most
appropriate here.
Exceptions: deprecation warnings are just warnings. Also, warnings that
are worded with uncertainty can remain warnings rather than criticals.
Using the Application Activation Manager coclass. Its threading model
is marked as 'both', so it can be instantiated in any apartment type
without marshaling.
glib_debug is an auto option. This is clever because it allows us to
guess the best default based on the build type, while also allowing an
easy way to override if the guess is not good. Sadly, the attempt to
guess based on the build type does not work well. For example, it
considers debugoptimized builds to be debug builds, but despite the
name, it is definitely a release build type (except on Windows, which
we'll ignore here). The minsize build type has the exact same problem.
The debug option is true for both build types, but this only controls
whether debuginfo is enabled, not whether debug extras are enabled.
The plain build type has a different problem: debug is off, but the
optimization option is off too, even though plain builds are distro
builds are will almost always use optimization.
I've outlined an argument for why we should make these changes here:
https://blogs.gnome.org/mcatanzaro/2022/07/15/best-practices-for-build-options/
Specifically, Rule 4 shows all the build types and whether they
correspond to release builds or debug builds. Rule 6 argues that we
should provide good defaults for plain builds.
