A portal frontend service for Flatpak and other desktop containment frameworks.
xdg-desktop-portal works by exposing a series of D-Bus interfaces known as
portals under a well-known name (
org.freedesktop.portal.Desktop) and object
The portal interfaces include APIs for file access, opening URIs, printing and others.
xdg-desktop-portal uses even minor version numbers for stable versions, and odd minor version numbers for unstable versions. During an unstable version cycle, portal APIs can make backward incompatible changes, meaning that applications should only depend on APIs defined in stable xdg-desktop-portal versions in production.
xdg-desktop-portal depends on GLib and Flatpak. To build the documentation, you will need xmlto and the docbook stylesheets. For more instructions, please read CONTRIBUTING.md.
Flatpak grants sandboxed applications talk access to names in the org.freedesktop.portal.* prefix. One possible way to use the portal APIs is thus just to make D-Bus calls. For many of the portals, toolkits (e.g. GTK) are expected to support portals transparently if you use suitable high-level APIs.
To implement most portals, xdg-desktop-portal relies on a backend that provides implementations of the org.freedesktop.impl.portal.* interfaces.
Here are some examples of available backends:
There are several reasons for the frontend/backend separation of the portal code:
The portal apis are all following the pattern of an initial method call, whose response returns an object handle for an org.freedesktop.portal.Request object that represents the portal interaction. The end of the interaction is done via a Response signal that gets emitted on that object. This pattern was chosen over a simple method call with return, since portal APIs are expected to show dialogs and interact with the user, which may well take longer than the maximum method call timeout of D-Bus. Another advantage is that the caller can cancel an ongoing interaction by calling the Cancel method on the request object.
One consideration for deciding the shape of portal APIs is that we want them to ‘hide’ behind existing library APIs where possible, to make it as easy as possible to have apps use them transparently. For example, the OpenFile portal is working well as a backend for the GtkFileChooserNative API.
When it comes to files, we need to be careful to not let portal APIs subvert the limited filesystem view that apps have in their sandbox. Therefore, files should only be passed into portal APIs in one of two forms:
When it comes to processes, passing PIDs around is not useful in a sandboxed world where apps are likely in their own PID namespace. And passing PIDs from inside the sandbox is problematic, since the app can just lie.