We’re close to having some useful xdg-desktop-portal support in snapd now. Once the following PR is merged, we should have enough to use the file open/save portal APIs:
https://github.com/snapcore/snapd/pull/5115
To test it, install the various packages:
- Build and install snapd from my branch (or wait for it to be merged to master)
- Install xdg-desktop-portal >= 0.11
- Install xdg-desktop-portal-gtk
- Install the portal-test snap from the edge channel:
snap install --edge portal-test
Now as the user ensure that the document portal is running (snap run won’t automatically start it yet) so that the $XDG_RUNTIME_DIR/doc mount is available:
systemctl --user start xdg-document-portal
On my system running Wayland, I needed to run xdg-desktop-portal-gtk in X11-only mode too since it was getting disconnected due to protocol errors: I need to do some more testing to see if this is a problem unique to my setup or not though. This can be achieved by running the following in a terminal:
GDK_BACKEND=x11 /usr/lib/xdg-desktop-portal/xdg-desktop-portal-gtk -v
Now run portal-test in another terminal. Click the “Save as…” button, which should show a file chooser that can see everything an unconfined app can. Pick a location to write a file, and portal-test should write the content “test” to that location. It does all this without using the home interface.
Under the covers, the process looks something like this:
- portal-test informs xdg-desktop-portal that it wants to save a file.
- xdg-desktop-portal asks xdg-desktop-portal-gtk to show the file picker and return the user’s selected file name.
- xdg-desktop-portal registers that file path with xdg-document-portal. This makes it available at a path like
/run/user/$uid/doc/$docid/$filename - it also asks xdg-document-portal to make the file available to portal-test, which also makes the file available at `/run/user/$uid/doc/by-app/snap.portal-test/$docid/$filename
- xdg-desktop-portal tells portal-test that it can write to
/run/user/$uid/doc/$docid/$filename. - Due to a bind mount in portal-test’s mount namespace, this actually maps to the
.../by-app/...path, so it is restricted to documents the app has access to. - portal-test opens the provided path, which the document portal FUSE file system splices through to the real location.
As I see it, there are still a few things to finish this off:
-
snap runshould launch xdg-document-portal prior to callingsnap-confinewhen a snap needs it. - xdg-desktop-portal needs some more metadata about snaps. As previously discussed, this is probably easiest to implement as an extra command on the snap executable that provides the required metadata.
- In particular, we need to be able to determine a desktop file ID for the snap, since we currently end up using
snap.$pkgname.desktopin some places which causes some problems (e.g. no app name in dialog, failures in notifications portal, etc)
- In particular, we need to be able to determine a desktop file ID for the snap, since we currently end up using
- document what snaps need to do in order to use portals. Some of this can be done via snapcraft-desktop-helpers, but it generally needs a newer GTK than found in xenial. It either needs the GNOME platform snap/backport PPA, or build with bionic once that’s sorted out.