Where applicable. Where the current use of `g_file_set_contents()` seems
the most appropriate, leave that in place.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
Helps: #1302
Give GAppInfo a bunch of readonly properties, and
support them in GDesktopAppInfo. This makes app infos
more convenient to work with in GTK4, and in general.
When an app is spawned using g_desktop_app_info_launch_uris_with_spawn
it will expand the various token in the app's commandline with the
URIs of the files to open. The expand_macro() function that is used for
this advances the pointer to the URI list to show up to which entries
it used.
To not loose the pointer to the list head a duplicate of the URI list
was actually passed to expand_macro(). However, it's not necessary to
create a copy of the URI list for that as expand_macro() will only
change which element the pointer will point to.
This behaviour actually caused the duplicated list to be leaked as the
the list pointer is NULL once all URIs are used up by expand_macro()
and thus nothing was freed at the end of the function.
This was mostly machine generated with the following command:
```
codespell \
--builtin clear,rare,usage \
--skip './po/*' --skip './.git/*' --skip './NEWS*' \
--write-changes .
```
using the latest git version of `codespell` as per [these
instructions](https://github.com/codespell-project/codespell#user-content-updating).
Then I manually checked each change using `git add -p`, made a few
manual fixups and dropped a load of incorrect changes.
There are still some outdated or loaded terms used in GLib, mostly to do
with git branch terminology. They will need to be changed later as part
of a wider migration of git terminology.
If I’ve missed anything, please file an issue!
Signed-off-by: Philip Withnall <withnall@endlessm.com>
Mention in the documentation that (presumably for performance reasons)
the search results from `g_desktop_app_info_search()` are not filtered
by executable presence or hidden attribute.
Perhaps they should be in future, but for now we should at least
document it.
Spotted by Will Thompson.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
There were some problems about where to install `gio-launch-desktop` to
support multiarch systems without circular dependencies. Simon McVittie
suggested that, actually, given the current set of platforms supported
by `GDesktopAppInfo` (they’re all POSIX), we could just use `sh`.
That simplifies things nicely. `gio-launch-desktop` can always be
resurrected (and the multiarch debate continued and resolved) if needed
in future.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
Fixes: #1633
It’s not enough to unref the monitor, since the GLib worker thread might
still hold a reference to it.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
Helps: #1903
`DesktopFileDir` pointers are passed around between threads: they are
initially created on the main thread, but a pointer to them is passed to
the GLib worker thread in the file monitor callback
(`desktop_file_dir_changed()`).
Accordingly, the `DesktopFileDir` objects either have to be
(1) immutable;
(2) reference counted; or
(3) synchronised between the two threads
to avoid one of them being used by one thread after being freed on
another. Option (1) changed with commit 99bc33b6 and is no longer an
option. Option (3) would mean blocking the main thread on the worker
thread, which would be hard to achieve and is against the point of
having a worker thread. So that leaves option (2), which is implemented
here.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
Fixes: #1903
For several years now (I haven’t looked up the exact date),
`gnome-terminal` has preferred being called as `gnome-terminal
--terminal-args -- /some/other/program --its-args` rather than as
`gnome-terminal --terminal-args -x /some/other/program --its-args`.
Since 2017 it has warned about uses of `-x` (see
ad4edbd118).
So we should change our calling convention for it.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
These have all been documented as deprecated for a long time, but we’ve
never had a way to programmatically mark them as deprecated. Do that
now.
This is based on the list of deprecations from the reverted commit
80fcb1bc2.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
Fixes: #638
Add support for mate-terminal and xfce4-terminal with higher precedence
over xterm as it's likely people that have those want to use them.
They both use the gnome-terminal `-x` switch instead of xterm's `-e`.
The g_app_info_launch_uris_async() and g_app_info_launch_uris_finish()
functions are crucial to fix g_app_info_launch_default_for_uri_async()
to be really asynchronous.
This patch also adds GDesktopAppInfo implementation of that vfuncs.
The implementation may still use some synchronous calls to local MIME DB.
https://gitlab.gnome.org/GNOME/glib/issues/1347https://gitlab.gnome.org/GNOME/glib/issues/1249
This causes the desktop directory cache to be correctly reloaded between
unit tests if G_TEST_OPTION_ISOLATE_DIRS is in use.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
The X-Flatpak-RenamedFrom key is used in .desktop files to identify past
names for the desktop file. It is defined to be a list of strings.
However, there was previously no correct way to retrieve a list of
strings from the GKeyFile wrapped by GDesktopAppInfo, short of
re-parsing the file with GKeyFile.
Note that doing something like:
g_strsplit (g_desktop_app_info_get_string (...), ";", -1)
is not correct: the raw value "a\;b;" represents the one-element list
["a;b"], but g_key_file_get_string() rejects the sequence "\;", and so
g_desktop_app_info_get_string() returns NULL in this case. (Of course, a
.desktop file with a semicolon in its name is a pathological case.)
Add g_desktop_app_info_get_string_list(), a trivial wrapper around
g_key_file_get_string_list(), similar to g_desktop_app_info_get_string()
and co.
The change from g_key_file_free() to g_key_file_unref() in the test is
needed because g_key_file_free() clears the contents of the keyfile.
This is fine for all the fields which are eagerly loaded and copied into
GDesktopAppInfo, but not when we want to access arbitrary stuff from the
keyfile.
Add an app-launching function which allows standard file descriptors
to be passed to the child process.
This will be used by gnome-shell to pass systemd journal descriptors
as stdout/stderr. gnome-shell's child_setup function can then be
eliminated, which will enable use of the posix_spawn optimized
gspawn codepath for desktop app launching.
In order to use the new posix_spawn gspawn codepath, for more robust
app launching when available memory is low, we need to meet some
conditions.
child_setup needs to be NULL for this optimization to work, so drop
the internal child_setup that is used here. Replace it with a lightweight
wrapper binary (gio-launch-desktop) that sets GIO_LAUNCHED_DESKTOP_FILE_PID
before executing the app.
Adjust PATH for gio tests so that it can execute the new binary from the
build directory.
The executable name can be a useful bit of information to match on in
searches where it differs from the name (for example because the latter
is localised), but will produce surprising results where the real appli-
cation is executed by a shared binary (for example interpretors like
gjs or python, or sandboxes like flatpak).
Address this by adding a blacklist of binary names that are ignored
in search.
https://bugzilla.gnome.org/show_bug.cgi?id=795488
The g_auto macros are available only with GCC-compatible compilers on
Unix, but having __attribute__((cleanup)) is not part of our toolchain
requirements, so we shouldn't use it — even if we are building on
Unix-compatible systems.
https://bugzilla.gnome.org/show_bug.cgi?id=794732
Custom desktop file fields may be translated, but there is currently
no non-hacky way to look up the localized value; fill get gap with
a small wrapper around g_key_file_get_locale_string().
https://bugzilla.gnome.org/show_bug.cgi?id=779413
If an application calls g_app_info_launch_uris() with a GList that includes
NULL values in some of its data members, and GIO ends up internally calling
g_desktop_app_info_launch_uris_with_spawn() for whatever reason (e.g. no
D-Bus session available), expand_macro() will crash due to the invalid data.
As this is considered a programmer error, use g_return_val_if_fail() in those
situations to prevent the crash from happening, but printing a warning anyway.
https://bugzilla.gnome.org/show_bug.cgi?id=791337
This list will be modified in-place when calling expand_macro(), so pass a copy
of it instead the original pointer, that is supposed to be an input parameter
only for g_desktop_app_info_launch_uris_with_spawn().
https://bugzilla.gnome.org/show_bug.cgi?id=791337
Bug #786580 triggered this warning to show up in the appinfo tests if
run on a machine where no terminal except xterm is installed (for
example, a build machine). Since we didn’t warn before if xterm but no
other terminals were installed, it seems reasonable to downgrade the
warning to a debug message.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
https://bugzilla.gnome.org/show_bug.cgi?id=790914
When we call org.freedesktop.Application.Open to activate
an application and pass file uris, the application may not
be able to see the files due to a flatpak sandbox.
Flatpak puts the flatpak app-id in the X-Flatpak key in
desktop files that it exports, so we can easily recognize
applications that may be affected by this.
In this case, call the document portal to export the files
and pass the resulting uri's instead of the original ones.
https://bugzilla.gnome.org/show_bug.cgi?id=783130
glibc string.h declares memcpy() with attribute(nonnull(1,2)), causing
calls with NULL arguments to be treated as undefined behaviour.
This is consistent with ISO C99 and C11, which state that passing 0
to string functions as an array length does not remove the requirement
that the pointer to the array is a valid pointer.
gcc -fsanitize=undefined catches this while running OSTree's test suite.
Similarly, running the GLib test suite reports similar issues for
qsort(), memmove(), memcmp().
Signed-off-by: Simon McVittie <smcv@debian.org>
Bug: https://bugzilla.gnome.org/show_bug.cgi?id=775510
Reviewed-by: Colin Walters
If we have an input parameter (or return value) we need to use (nullable).
However, if it is an (inout) or (out) parameter, (optional) is sufficient.
It looks like (nullable) could be used for everything according to the
Annotation documentation, but (optional) is more specific.
GApplication has accepted any valid bus name as an application ID since
before the time of D-Bus activation. This includes bus names with '-'.
Several applications have even attempted support bus activation with
these names, going as far as installing D-Bus service files, without
realising that they are silently falling back to fork()/exec() on
account of the name containing a dash.
The reason for the problem is that D-Bus object paths cannot contain
dashes. We solved this problem privately in an unspecified way inside
of GApplication but substituting '_' in this case, but never made this
part of the Desktop Entry Specification.
The fact that these apps with '-' in the desktop file names aren't
actually using D-Bus activation is beside the point: their intent here
was clear. Let's avoid forcing them to rename their desktop files again
by simply accepting '-' in desktop file names and munging the path in
the way that GApplication did so historically.
The new path escaping code here has been copied more or less verbatim
from GApplication's own code for the same purpose, with only the removal
of one irrelevant part.
An update to the desktop entry specification will follow.
https://bugzilla.gnome.org/show_bug.cgi?id=764754
The environment variable DISPLAY makes sense only for X11, it should
not be set in gio.
Beside, if the backend is not X11 but Wayland, forcing the value of
DISPLAY to the Wayland display will confuse the backend selection and
possibly crash the applications.
https://bugzilla.gnome.org/show_bug.cgi?id=754983
Always run the full algorithm for a given mime type before considering
fallback types.
This includes considering installed applications capable of handling a
particular mimetype, even if such an app is not explicitly marked as
default, and there is a default app for a less-specific type.
Specifically, this often helps with cases of installing apps that can
handle a particular subtype of text/plain. We want to take those apps
in preference to a generic text editor, even if that editor is listed as
the default for text/plain and there is no default listed for the more
specific type.
Because of the more holistic approach taken by the algorithm, it is now
more complicated, but it also means that we can do more work while
holding the lock. In turn, that lets us avoid duplicating some strings,
which is nice.
https://bugzilla.gnome.org/show_bug.cgi?id=744282
Remove all event merging and dispatch logic from GFileMonitor. The only
implementation of GFileMonitor outside of glib is in gvfs and it already
does these things properly.
Get rid of GLocalDirectoryMonitor. We will use a single class,
GLocalFileMonitor, for both directory and file monitoring. This will
prevent every single backend from having to create two objects
separately (eg: ginotifydirectorymonitor.c and ginotifyfilemonitor.c).
Introduce GFileMonitorSource as a thread-safe cross-context dispatch
mechanism. Put it in GLocalFileMonitor. All backends will be expected
to dispatch via the source and not touch the GFileMonitor object at all
from the worker thread.
Remove all construct properties from GLocalFileMonitor and remove the
"context" construct property from GFileMonitor. All backends must now
get the information about what file to monitor from the ->start() call
which is mandatory to implement.
Remove the implementation of rate limiting in GFileMonitor and add an
implementation in GLocalFileMonitor. gvfs never did anything with this
anyway, but if it wanted to, it would have to implement it for itself.
This was done in order to get the rate_limit field into the
GFileMonitorSource so that it could be safely accessed from the worker
thread.
Expose g_local_file_is_remote() internally for NFS detection.
With the "is_remote" functionality exposed, we can now move all
functions for creating local file monitors to a proper location in
glocalfilemonitor.c
Port the inotify backend to adjust to the changes above. None of the
other backends are ported yet. Those will come in future commits.
Commit e24e89b accidentally ironically introduced a typo when replacing
the code with symbolic contents. Specifically, "Added Associations" was
replaced with "Default Applications" when reading defaults.list, giving
a warning about the file containing a "Default Applications" group.
If this was intended, it should have not been lumped in with a cleanup.
