Application-Themed/Branded Folder Icons?

[elsiehupp]

Problem

Directories that are native to the operating system (i.e. Documents, Downloads, etc.) have overlays, coloration, and mini glyphs to distinguish them from regular directories. However, certain directories not provided by the operating system are programmatically created, yet still look like user-created directories.

Most prominently, Snap creates a top-level directory in the user's home directory, and it can't be renamed or moved (though it can be hidden by referencing it in .hidden). Similarly, cloud-sync services often create or require one or more branded directories, which can be placed anywhere but usually also default to the top level of the user's home directory.

Issue #665 specifically talks about directories inappropriately residing at the top level of a user's home directory, but folder icons are determined by metadata keys, rather than their location in the directory structure. For example, the Documents folder has the following:

$ gio info ~/Documents | grep icon
  standard::icon: folder-documents, folder, folder-documents-symbolic, folder-symbolic
  standard::symbolic-icon: folder-documents-symbolic, folder-symbolic, folder-documents, folder

Using gio for icon theming, while an application-specific folder could inappropriately reside at the top level of a user's home directory, it could just as easily reside anywhere else and still use a themed icon.

The idea of a generic cloud-service folder was presented in Issue #742.

Issue #721 also asks about application-themed folder icons, such as Git, Code, etc.

Unlike application icons—which elementary deliberately declines to override—application-themed folder icons incorporate a generic folder icon, which is then customized. Because folder icons used by icon themes vary widely, it is impractical for application developers to provide special folder icons that coordinate with any and every icon theme. I don't know if it's even possible to applications to programmatically poll the operating for the name of applicable icon theme in the first place.

Proposal

In order to facilitate application-themed folder icons that specifically match the elementary icon theme, elementary icons (as well as other major icon-set developers) could create a more open-ended specification for constructing and naming these icons. For example, based on folder-documents and folder-documents-symbolic, the elementary icon theme could, with the cooperation of application developers and on an ad hoc basis, incorporate icons such as folder-cloud and folder-cloud-symbolic, folder-git and folder-git-symbolic, or even more specific names such as folder-nextcloud and folder-nextcloud-symbolicor folder-calibre, folder-calibre-symbolic, folder-joplin, folder-joplin-symbolic, etc.

Again, this would be on an ad hoc basis and with the cooperation of application developers, who regardless would be the ones to use gio to assign their preferred folder icons, rather than leaving the assignment up to the operating system itself.

I recognize that the particular folder-naming schema I just presented may not be ideal. For example, it may be preferable to use reverse-domain strings, like folder-com.nextcloud.desktopclient or similar, to match the reverse-domain strings used by the applications themselves.

Also, it would presumably be necessary for the icon design guidelines to provide specifications for conforming modifications to the default folder icons, like whether the folder can be recolored, what sort or size of glyph may be used, etc.

Finally, yes, I know there are relatively detailed specifications around which icons a freedesktop.org-compliant icon theme should provide and what they should be called, but looking at #827, it does appear that the maintainers here are open to limited modifications to the icon-naming lexicon.

Prior Art

This isn't exactly prior art, but I threw together a folder icon for the Humanity icon set over at Nextcloud Desktop, and similarly both macOS and Windows have semi-established precedents for certain folders (particularly cloud-sync folders) having special icons in certain contexts.

While, yes, cloud "drives" can be mounted as virtual devices rather than folders, it is much more the norm for cloud-drive clients to sync with a regular directory than to mount as a drive. Even when a cloud-sync directory is represented in the sidebar as something other than just a folder, it still usually resides in the regular filesystem somewhere in the user's home directory.

[danirabbit]

I'm not sure it's super worth pursuing this route when the future we're working towards is a sandboxed one, so apps will not be able to create directories in users' home at some point

[elsiehupp]

Regarding sandboxing, sandboxed application directories could still be nice to have themed with special icons. For example, sandboxed application directories in iCloud Drive use icons derived from the applications that created them.

[elsiehupp]

Depending on how sandboxing works with Flatpak, themed-icon metadata might be better implemented by Flatpak rather than by the applications themselves, but I don't know enough about the nitty-gritty to know what would be involved.

[elsiehupp]

On a different subject, looking at the illustration of an inset-pictogram icon from the elementary icon-design guidelines:

It's easy to imagine folder icons being programmatically created from the default folder, the symbolic icon, and possibly an alternate fill color. The "embossed" stylization is standardized enough that that folder-icon rules could be enforced at the time of creation (which could also simplify creating the icons in the first place).

[elsiehupp]

Also, in terms of which applications would be eligible for themed folder icons, in the case of elementary, it could be reasonable for themed folder icons to be a special aspect of curated AppCenter applications, rather than something completely thrown open to all developers. (Though if themed folder icons were implemented on the Flatpak level, Flathub could figure them out, too.)

[hanaral]

It might be nice to have something like iOS where each app has its own sandboxed folder that it can use as its user-accessible folder rather than having to use the user's Documents, Pictures etc.
So essentially ecosystem of sandboxing where apps only see what they need to see - and have to ask via a popup to access another app's files.

Another cool idea would be to have these 'App storage' spaces have a static shortcut in the Files sidebar (and possibly the save dialog)

[elsiehupp]

I'm pretty sure this is how it works with both Flatpak and Snap. The main difference between the two is where the choose to put the sandboxed userdata folder. In both cases, though, it's 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 the folders technically live in ~/Library/Mobile Documents/<app-id>, and then Finder, the Files app, and Open... and Save... dialog boxes pretend that they live in the iCloud Drive folder, which itself actually lives in ~/Library/Mobile\ Documents/com~apple~CloudDocs/. All of the user-friendliness is done through trickery with the file browser's user interface.

[hanaral]

I didn't mean to present the user with the actual flatpak folder struture, I meant a simple virtual folder like the recents tab that has a bunch of the 'App spaces' in it.
I don't know much about snaps, but they aren't the official method of getting apps like flatpak will be.

[elsiehupp]

Ehhhh... Snap has the force of a commercially significant distribution behind it. Yes, it's annoying that it's separate from Flatpak, but at the end of the day it's a functionally equivalent way of doing more or less the same things.

[danirabbit]

This is sounding to me like more of an issue to be pursued in GVFS. If you want to have a location that you can view app data in the same way that you can with say "trash://" or "recent://", GVFS is where that code lives

So I'm inclined to close this as "out of scope" for elementary. If the maintainers of GVFS are opposed to this idea, then maybe it could be brought up against Files, but if we had to maintain support for this it would only support Flatpak and not Snap since development resources are limited

[elsiehupp]

@danrabbit This is sounding to me like more of an issue to be pursued in GVFS. If you want to have a location that you can view app data in the same way that you can with say "trash://" or "recent://", GVFS is where that code lives

Cool, thanks for pointing me an that direction! I'll dig around in the GVFS issue tracker and see if there's a good place to put a version of this issue there.

[elsiehupp]

If you're curious, the issue I created on the GVFS issue tracker is here.