Portal components in native applications

  • Arch Linux | Kernel 6.6.1
  • Gnome-shell | Mutter 45.1
  • Wayland (gnome-shell --no-x11)
  • Evolution: 3.50.1
  • Xdg-desktop-portal 1.18.1

Newbie here to the world of portals after having them foisted upon me via dependencies:

│ └─file-roller
│ └─nautilus
│   └─python-nautilus
│     └─nautilus-open-any-terminal

I do no use flatpak in any fashion. So, I’m curious about a few things…

  1. Why do native applications have portal components and/or sandbox expectations?
  2. Can these be disabled at build time?

I opened (and closed after building xdg-desktop-portal main), this issue:

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.

1 Like

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.

Thank you for the speedy response!

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 is listed 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.




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.

1 Like

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.


1 Like

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.

Oops, looks like I forgot to update this topic.

Thanks to the investigatory efforts of @mcrha, it looks like the root cause of the issue that drew my attention to this topic lies within the implementation of WebKit’s sandbox.

I’ll go ahead and file an issue (including all that valuable info) with WebKit or WebKitGTK.

This topic was automatically closed 45 days after the last reply. New replies are no longer allowed.

After I finally got around to filing this issue against WebKitGTK, it’s now come full-circle to where I began.

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.

This ended up being fixed in Webkit.

I built webkit2gtk-4.1 2.42.4 + WebKit/WebKit#23052, and can confirm it resolved this.