And see here for the new Evolution-specific issue:
The Evolution application package has no portal dependencies, but expects a sandbox regardless?
I assume this is an outright bug, but per @mcrha… “The only portal Evolution talks to directly (over D-Bus) is org.freedesktop.portal.Settings on org.freedesktop.portal.Desktop, to get notifications about color scheme changes.”
Can any portal/flatpak experts here help me understand such hooks into native apps? Thanks in advance for any guidance.
Broadly speaking, there’s nothing magical about portals; they’re just D-Bus services. They don’t require sandboxed applications to be useful, and in many cases, they are the only cross-desktop interface available.
What do you mean by expectations?
If you’re asking about a dependency on libportal, it is simply a small client-side D-Bus library. As far as I know, libportal does not depends on a portal service to actually be running or installed.
That depends on the application and its build system, but again, libportal is really just a convenience wrapper around D-Bus calls.
So, this dependency of libportal on xdg-desktop-portal would be a packaging issue specific to Arch linux? (See Required By:)
$ pacman -Qi xdg-desktop-portal
Name : xdg-desktop-portal
Version : 1.18.1-1
Description : Desktop integration portals for sandboxed apps
Architecture : x86_64
URL : https://flatpak.github.io/xdg-desktop-portal/
Licenses : LGPL
Groups : None
Provides : None
Depends On : fuse3 gdk-pixbuf2 geoclue glib2 pipewire rtkit systemd
Optional Deps : xdg-desktop-portal-impl: Portal backends [installed]
Required By : libportal xdg-desktop-portal-gnome xdg-desktop-portal-gtk
Optional For : firefox
Conflicts With : None
Replaces : None
Installed Size : 2.28 MiB
Packager : Jan Alexander Steffens (heftig) <heftig@archlinux.org>
Build Date : Thu 26 Oct 2023 11:59:24 AM EDT
Install Date : Sat 11 Nov 2023 02:13:14 PM EST
Install Reason : Installed as a dependency for another package
Install Script : No
Validated By : None
I’ll see if I can build libportal locally sans the xdg-desktop-portal dependency. But, it islisted as a make-deps.
Another question on the same topic…
When I first installed xdg-desktop-portal, it would complain in the system journal about the following:
Oct 23 11:48:20 xdg-desktop-por[161571]: Choosing gtk.portal for org.freedesktop.impl.portal.Inhibit via the deprecated UseIn key
Oct 23 11:48:20 xdg-desktop-por[161571]: Choosing gnome-shell.portal for org.freedesktop.impl.portal.Access via the deprecated UseIn key
Oct 23 11:48:20 xdg-desktop-por[161571]: Choosing gtk.portal for org.freedesktop.impl.portal.Email via the deprecated UseIn key
Oct 23 11:48:20 xdg-desktop-por[161571]: Choosing gnome-keyring.portal for org.freedesktop.impl.portal.Secret via the deprecated UseIn key
Should each of these be filed as bugs against their respective components?
I noticed that if I changed my default portal, the list of complaints would change accordingly.
I worked around these by hard-wiring each portal in my config. ~/.config/xdg-desktop-portal/portals.conf
Using gnome as the default portal yielded the fewest overall errors when the xdg-desktop-portal service started, so I just rolled with it based solely on that fact haha. This may just be neurosis on my part …I want an error-free journal!
I wouldn’t call it a packaging issue. It makes sense when packaging to have the client (libportal) depend on the service (xdg-desktop-portal), but you can open an issue with your distribution if you like.
They’re deprecation warning, so they should be fixed eventually. Not critical by any means, though.
I just wanted to see what would happen. While libportal, and its gtk* couterparts, all built successfully without the dependency… ooooh boy a lot of apps, and dbus itself are mighty unhappy without xdg-desktop-portal and its brethren installed haha! I’ll be undoing this right quick. Fun experiment.
I now understand this idea is senseless, and would be closed immediately by the maintainer.
Right. This is all I was getting at, the use of the deprecated key/method.
Portals are considered to be a desktop-agnostic and toolkit-agnostic way for an app to access system resources, especially sensitive system resources, in a way that doesn’t require specific knowledge of the rest of the desktop environment
They can work whether or not an app is in a sandbox or which sandbox technology is employed, and they work whether or not the desktop environment is KDE/GNOME/etc, and many of the portals should even work regardless of whether the system is Xorg or Wayland-based
And for confidential/sensitive system resources, they provide a useful place for desktops to implement user consent dialogs, etc
I imagine that any app making use of libportal will probably pause and time out whenever attempting to access a portal on systems where xdg-desktop-portal is absent or broken
The example you mention about the Settings portal is very useful for developers, because it means there’s finally one universal documented method for the user to express their preference of dark/light mode, etc, so app developers and toolkit maintainers no longer need to care about KDE/GNOME/etc specifics
Thanks for your synopsis here! I’m slowly getting up to speed on this topic finally.
While the codebases of DEs and compositors are outside out of my domain, I can draw some similarities with various abstraction layers I’m intimately familiar with.
Hopefully this can be solved fully within xdg-desktop-portal. There are a couple of ideas presented, so I’m hopeful. A clean journal is a happy journal.
I’ll try to keep this topic open/updated through time of resolution, as more non-flatpak sandboxes come into existence in various native apps.