`GDBusProxy` implements this interface but allows construction with a
`NULL` interface info and also marks its getter/setter for the interface
info accordingly.
Callers of `g_dbus_interface_get_info()` need to assume that it can
return `NULL` unless they constructed the `GDBusInterface` in a way that
guarantees that the interface info is available.
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
This step is no longer "hidden away in the infrastructure" but now in
the open.
Background: some GLib tests can fail with timeouts because of some
assumptions regarding the temporary directory that don't work out on
macOS. Until this is properly investigated and resolved, the
workaround is to redirect it to a ramdisk.
Also add ORKA_RUNNER variable as the macOS CI infrastructure evolves.
Future changes to the image can be controlled this way.
Fixes https://gitlab.gnome.org/Infrastructure/Infrastructure/-/issues/2091
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
