The connectivity is directly derived from the `is_available` variable,
so if that changes, we need to notify of a change in `connectivity` too.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Fixes: #3803
We have some (deprecated) methods that technically still return
transfer-full instances of GTypeClass's and GTypeInterface's.
The introspection scanner cannot generate bindings for them though since
it does not know how to manage their lifecycle, and we end up skipping
these symbols.
This is breaking some language bindings, and in particular gjs [1] and
lua-lgi, that were using the .ref methods.
While we should not use deprecated functions in the language bindings,
these symbols should still be introspected.
[1] https://gitlab.gnome.org/GNOME/gjs/-/issues/711
Partially reverts commit cad84d5e27.
When a snap is launched from its non-dbus-activable desktop file we may
still need to use the portal to pass the URIs to the program, so that it
can access to them even if confined.
In fact most snaps are not dbus-activable, but they rely on the classic
desktop file activation.
Seems scan-build is incorrectly assuming that `output != NULL` at the start
of the function (so `file` is opened), and then later assuming that
`output == NULL` (so `file` is not closed).
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Keep the old error reporting FD around until duping it has worked,
otherwise we don’t have an FD to report errors on.
Spotted by scan-build.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
We were previously relying on it returning `EINVAL` so we could return
an error message, but scan-build doesn’t like that, so let’s just
explicitly return the same error anyway to shut scan-build up.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
The value of `errno` can apparently be undefined after a successful
function call (according to scan-build), so only check `errno` on
failure.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Snap applications like flatpak apps may need to use the portals to open
files, so use the same logic that we have for flatpaks but using the
snap ID that matches portal expectations
We were checking the results of opening an sandboxed application, but
never if the open was actually invoked.
So if another desktop file was used in tests, we were never getting any
failure, at least not related to the lack of a file being opened
Rather than reporting an error via a new `GTask`, report it via the
`GTask` we’ve already created. This avoids a critical warning about
destroying the `GTask` without returning a result.
Also ensure to disconnect the D-Bus signal subscription first, to avoid
an assertion failure in `call_data_free()`.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Fixes: #3798
As per commit 0144feb41 the activate action paramter may pack multiple
values but while the behavior was checked we did not check the content
of the values we were receiving in the action callback.
So, also ensure that the variant values we receive are matching the
expectations.
Instead of guessing the portal file name by using the original file name
let's just inspect the portal document ID directory and get the actual
file name
In order to properly test the document portal, let's also create some
dummy files that are named after the FDs we receive and using the
document-id path as the real portal does
When an URI to a symlink is added to the portal, we open it and we send
the FD (of the target) to the portal. This one has no clue about the original
symlink and so it mounts a file that is named like the target.
g_document_portal_add_documents(), however returns a path that contains
the original name and that one is what is sent to the applications when
used via GDesktopAppInfo.
Basically, this is the situation:
- /tmp/symlink -> /tmp/target
- An application is launched to open file:/tmp/symlink
- The portal creates file:/$XDG_RUNTIME_DIR/doc/ID/target
- Gio converts the path to file:/$XDG_RUNTIME_DIR/doc/ID/symlink
Now, since we can't just pass the symlink to the portal without also
changing the logic there, it's just better to do the conversion ourself,
and so, we use the already-opened fd to figure out the real path of the
opened file, and we return a document file URI that uses the target
basename instead
Fedora 39 is out of support so, as per our policy, update the CI image
to the oldest still-supported release, which is 41.
systemtap-sdt-dtrace needs to be installed separately (for the `dtrace`
binary), as it appears to have been split out of some other package.
Update the mingw CI image too, as it’s built on top of the Fedora one.
Update the supported platforms documentation.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
It routinely fails with subproject fetch errors, typically at least
every second CI run. This wastes a lot of CI machine time, and a little
bit of developer time and energy each time (in noticing that it’s
failed, context switching, checking the failure, retrying it, context
switching again).
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
See: https://gitlab.gnome.org/GNOME/glib/-/issues/3715
- Redid the old StarOffice-format drawing file in OpenDocument
format, and updated with two different `-light` and `-dark`
versions.
- Added color to the rectangles
- Bolded all of the text
- Added background transparency
- Exported both as `file-name-encodings-{light,dark}.svg`
- Tweaked in Inkscape to simplify SVG structure, scale to
fixed pixel sizes, align to page dimensions.
- Added License/Copyright data as Custom Document Properties
in OpenDocument sources, comments in SVG source.
- Federico Mena Quintero, uploader of the originals, is
credited in the `SPDX-FileCopyrightText` data, along
with myself.
- License chosen was `CC0-1.0`, because again I don't believe
these files are complex enough to actually be copyrightable.
- Added data for `.odg` files to `/.reuse/dep5` file, as
reuse can't extract license data from that format.
- Updated `character-set.md` and `glib.toml.in` to use
new SVGs in place of old PNG.
