Skip to content

Please provide an xfce-portals.conf for xdg-desktop-portal >= 1.17

Context

xdg-desktop-portal is a D-Bus service providing access to desktop-environment-related functionality for applications. It was originally written to provide sandboxed apps (Flatpak, Snap, etc.) with limited access to resources outside their sandbox with user consent, but is increasingly also used by non-sandboxed apps (.deb or equivalent) as a desktop-environment-independent interface to features like screen-sharing that are otherwise difficult to implement in a cross-desktop way.

x-d-p itself does not contain any desktop-environment-specific code, and is shared between all desktop environments. However, a lot of what it does requires use of desktop-environment-specific mechanisms or user interface conventions. To allow for that, it contacts a desktop-specific backend (x-d-p-gtk, x-d-p-gnome, x-d-p-kde and so on) and uses that to provide its full functionality.

XFCE doesn't currently have a desktop-specific backend of its own, although there is some discussion in #159 about whether it should. Until/unless it does, there are a couple of options for what XFCE could use:

  • x-d-p-gtk was originally written for GNOME, but most of its GNOME-specific bits have now been moved into x-d-p-gnome, and it's common to use it in desktop environments that don't have their own portal backend. It currently uses GTK 3 dialogs for its UI.

  • x-d-p-xapp was written by Linux Mint developers and claims to support Cinnamon, Mate and XFCE - although Mate developers seem to be unhappy about it, and I don't know whether any XFCE developers have been involved in its development or testing. It doesn't implement the Lockdown interface on XFCE, and the Screenshot implementation for XFCE seems rather half-finished (I'm not sure whether it really works outside Cinnamon in practice).

The issue

In older versions of x-d-p, if x-d-p does not find a suitable backend for the current desktop environment, it would fall back to trying any backend. This meant that all backends needed to be prepared to run in an environment where their functionality cannot actually work, which is rarely tested, leading to undesired situations where a desktop environment's backend can cause bugs (such as crashes or slow application startup) while running different desktop environments.

In the x-d-p 1.17.x prereleases and the upcoming 1.18.x stable release, this has been changed to give desktop environment developers more control over the backends they use. As described in https://github.com/flatpak/xdg-desktop-portal/blob/main/doc/portals-conf.rst, the recommendation is now that each desktop environment should provide a file listing its preferred backends, similar to the one added by https://gitlab.gnome.org/GNOME/gnome-session/-/merge_requests/95/diffs in GNOME. This mechanism is similar to mimeapps.list, and it makes sense to configure it in some "reasonably central" desktop package - in GNOME, it's gnome-session that took responsibility, and in XFCE, xfce4-session seems like a reasonable place.

A simple implementation would be to write this into ${datadir}/xdg-desktop-portal/xfce-portals.conf:

[preferred]
default=gtk;

or if you want to use the -xapp implementation if available, maybe something like this:

[preferred]
default=gtk;
org.freedesktop.impl.portal.Inhibit=xapp;gtk;
org.freedesktop.impl.portal.Wallpaper=xapp;gtk;

Most desktop environments implement most portal backends in the same service, but it's possible to divide up responsibility between multiple D-Bus services. If someone writes a -xfce backend that installs an xfce.portal file, then you'd also want to add xfce to one or more of these lists. Similarly, if Thunar wants to register as a backend for the FileChooser interface (thunar#547), you'd probably want something like org.freedesktop.impl.portal.FileChooser=thunar;gtk;. See https://gitlab.gnome.org/GNOME/gnome-session/-/merge_requests/95/diffs for a real-world example of a non-trivial portal configuration like this.