flatpak:// backend for sandboxed userdata folders?
EDIT: I've cross-posted this on both the Flatpak and Nautilus issue trackers.
Flatpak (as well as Snap) creates sandboxed userdata folders for individual applications, but they are not terribly user-friendly:
- with Snap, the sandboxed userdata folders are broken down by version like
~/snap/<app-name>/<version>/~
, and each one is mapped onto a virtual home folder, like~/Library/Containers
on macOS, so, for example, an application that uses hidden folders like.config
or.local
would have those same folders—still hidden—in their Snap userdata folders. - with Flatpak, the sandboxed userdata folders follow XDG conventions, so, for example,
XDG_DATA_HOME
is~/.var/app/<app-id>/data
, which is, of course, inside a hidden folder.
By contrast, the way Apple does user-accessible app-specific folders (i.e. on iCloud Drive or iOS Files) is that, while folders technically live in ~/Library/Mobile Documents/<app-id>
, the Finder, the Files app, and the Open... and Save... dialog boxes pretend that the folders live in the iCloud Drive folder, which itself actually lives in ~/Library/Mobile\ Documents/com~apple~CloudDocs/
. (There are separate sandboxed home folders for application data that doesn't need to be user-accessible.)
I mentioned this issue over on the elementary OS issue tracker, and the maintainer there pointed me in the direction of GVFS as a better place to talk about this. Basically, my suggestion is that Flatpak userdata folders could be mapped onto flatpak://
in order for GUI file browsers like Nautilus to be able to present them in a more user-friendly way, perhaps similar to the way that Apple does "App Libraries".
For consistency, this backend could more generalized to appdata://
or something similar in order to incorporate some degree of support for Snap applications, as well. (Including non-sandboxed applications' userdata folders might be more complicated due to the fact that they don't have as predictable userdata locations, and it might be desirable to gatekeep the feature as an incentive for developers to adopt sandboxing.)
As an extension of centrally listing these application folders, it also could be nice to have a framework for frontend developers to be able to programmatically create folder icons, perhaps using the registered icons from the applications' .desktop
files. (Registering folder icons was my original intention in pursuing this issue.)
I'm very much not in a position to implement this myself, and I don't know enough about the architecture of GVFS to make any real technical suggestions, but on an abstract level, does this seem like a feasible and worthwhile feature to pursue?