Thanks for getting this conversation started.
I understand you’d like to improve the user experience in graphic applications, which is a noble goal. It’s important we clarify what is or is not possible with snaps, though.
In particular, the stated goal is not by itself an actual limitation in snaps. There are today multiple ways in which files and resources of all kinds from the host may be made available to snaps. Not only that, but snapd can also easily be extended to access data via pretty much any method that the hosting system supports. We already have backends and interfaces interacting with dbus, apparmor, seccomp, mount subsystem, and a few others today.
With that out of the way, fine tuned support for xdg-desktop-portal and any other intermediation mechanism that real applications depend on is very welcome. Similar to how deb packages, or rpm packages don’t really say what APIs we’re supposed to be using in your applications, snaps won’t constrain us to any particular API either. If the application wants to use a dbus API to ask for a file, that’s find and trivial today. If it wants to do an old school open system call, there are good ways to mediate that as well.
That sounds easy and fine.
It might also not even be necessary. We recently landed a general dbus interface which allows declaring in its definition what specific resources are being used across the wire. A first class interface might be more convenient for people, though.
That part seems suspect. The application (and the XDG protocol?) shouldn’t have to know how it’s being packaged to tell how to request access to a file.
Sounds reasonable and simple.
Please let us know how you’d like to proceed. Would you like to try cooking a strawman interface?