Prettify ~/snap Folder Somehow?

[elsiehupp]

Problem

If you install literally any Snap application (which can be unavoidable), it will create a folder at ~/snap, and this folder cannot be renamed or moved without breaking Snap. The obtrusiveness of the ~/snap folder has been an open issue on the Snap issue tracker for over four years, with little indication of any sort of action.

Part of why the ~/snap folder is annoying is that it isn’t a hidden folder (though apparently the long-term plan is for it to be moved to ~/.snap, not even ~/.var/snap tsk tsk), and also it isn’t title case, i.e. ~/Snap. Also the folder doesn’t have a dignifying fancy icon like the rest of the default folders in ~.

Proposal

There are a few ways the ~/snap folder could be prettified, including:

1. Ship Elementary with a file at ~/.hidden that marks ~/snap as hidden (assuming Pantheon Files supports the use of ~/.hidden in the first place).
2. Hardcode some sort of workaround that makes ~/snap appear as ~/Snap, the difficult thing being doing so in Pantheon Files without creating an inconsistency with the Terminal and also without breaking Snap.
3. Possibly in combination with item (2), create a nice embossed folder icon for ~/snap like all the other default user folders have and apply it when the folder is created.

A while back I opened an issue that ended up with @danrabbit suggesting creating some sort of gvfs plugin that would combine the Snap and Flatpak user folders into a more user-friendly interface, but nothing has come of that, and I don’t have the skills necessary to implement it myself.

Basically option (1) above (possibly with some sort of GUI preference for toggling it) could be a short-term workaround for the Canonical team’s extremely slow progress on the issue.

Prior Art (Optional)

No response

[jeremypw]

Needs design team input as to the best solution but one of the simplest would be to hide Snap folder (the flatpak one is already hidden). Rather than having to check a list of filenames in ~/.hidden which might impact performance, maybe it would be possible to add some custom metadata to the folder (in the same way as the color tag works) which would cause Files to ignore it.

[jeremypw]

Implementing a non-standard protocol such as flatpak:// in files might be possible and would be handy to check,say, what flatpaks are installed (and uninstall them?) but I guess that is encroaching on AppCenter territory. Better implemented upstream though.

[elsiehupp]

FWIW I would tend to lean towards combining the list Flatpak and Snap (and maybe even apt) applications into a single appdata:// or just apps:// virtual filesystem. This could provide a frontend for sandboxed data folders but could potentially also provide a frontend for editing .desktop files (i.e. editing the application launcher; I forget what it’s called).

One thing that would have to be figured out with this is which of an application's data folders should be easily accessible to the user through the virtual filesystem. Enumerating these folders could potentially be a part of the AppStream specification, though I’m not sure how it should be implemented.

For editing .desktop files, basically the “properties” dialog would be adapted to represent the XML fields, kind of like editing a .lnk file on Windows, though with the additional features the .desktop specification includes that .lnk does not. The “properties” dialog for .desktop files wouldn’t have to show all of the XML fields, just the ones that the Files developers think would be useful to typical end user. Like the obvious ones would probably be the application icon and display name, as well as a toggle for whether the application should be shown in the launcher menu. (Notably all of these are related to the GUI appearance of the application icon.) Things like the shell command for launching the application could be omitted or hidden behind an “advanced” disclosure triangle.

This is a bit of a digression from the original topic, though.

[jeremypw]

Non standard virtual filesystems would need to be implemented at system level or upstream so that all filemanagers and apps could benefit.

[elsiehupp]

I mean, yes. Definitely! It would make the most sense to add features like these to GVFS (with the cooperation of Flatpak, et al). Again, this is well beyond what I’m personally capable of implementing.