[Feature Discussion] Snapd can copy the icon directories

Currently, the snapd only copies icons which are in the meta/gui folders. But, the problem is Snapcraft doesn’t allow to icons with names org.example.app there. It has to be snap.SNAP_NAME.org.example.app. Which is often just an extra step to do these. What the snapcraft currently does is rename the Icon key with the path of the actual icon. Potentially, locking the icon and removing the chance of using themed icons. But, what we can do is, just copy the $SNAP/usr/share/icons folder to /var/lib/snapd/desktop and also, make some changes to show up the icon instantly after installing the app. This also keeps the path open for themed icon, and reduces the need of a separate icon theme snap.

There’s already hidden support for using named icons rather than absolute paths; it’s currently still hidden because there’s no mechanism for defining an alias for them. So while you can technically theme them, you’d need the theme to compensate for the specific snap until icon aliases are properly in place. Unfortunately I’ve not seen any work on this in the past few years.

For the desktop file, the Icon= line would be e.g Icon=mysnapname and you’d need the file to be in e.g: ${SNAP}/meta/gui/icons/hicolor/scalable/apps/snap.mysnapname.svg

The result should be that the icon continues to work as expected but the user could theme it because rather than hardcoding to the snap, it’ll search the users themes for the name. In most cases this will end up using the snaps icon but it offers the user a chance to replace the icon without replacing the entire .desktop file

I know, and it’s very hacky :sweat_smile: and not only icons, even we need to make some changes to the metainfo.xml file. Cause, else, snapcraft automatically replaces that.

But, still just copying that /meta/gui with those names, would be just so better

It’d be easier than the undocumented approach but there’d still be a lot to factor in. Mostly, what happens in the event of duplicate names? Without proper mediation you’d be allowing any given snap to overwrite other snaps icons. This might be harmless in most contexts but there’s a lot of snaps that duplicate functionality (looking at you, Minecraft!) and might reasonably have the same name. Then what happens if you remove one of them? What happens if one snap decides to change it’s icon to something less generic and now every other snap using the same name is forced into it too.

Ultimately the package manager needs to be able to keep track of which file is owned by which snap, which isn’t easily done when there’s the potential for an unbounded many to one relationship.

We can simply force the snaps to use icons with their names, or can make use of the common-id here. i.e, if a snap has a name example the icons allowed would be example.svg or org.example.com.svg.

Generally that might be an improvement on what currently exists, but there’s still more questions.

E.G, firefox --> firefox.png probably works fine. But how do we deal with E.G LibreOffice, which has several different icons. They might all follow a similar pattern, but we can’t know in advance what that pattern actually is. If we end up forcing something like LibreOffice.Writer.Png, and the theme designers are only expecting Writer.Png, you effectively just end up in the same position we already are where theming doesn’t work. If we end up forcing a similar system to reverse domain names, that’s almost already what’s happening with the snap.snapname.svg approach.

I’ll leave some room in here for other people to chime in. I’m all for enabling better icon theming support, but I can see why there’s a load of edge cases that means this hasn’t been looked at properly in a while. In a ‘normal’ system like a distribution repository, there’s a coordinated effort taken to avoid this being a problem. With a more free for all approach, I’m not sure there even is a solution that generally covers every case, and it might just be a case of picking the least bad option rather than the most good one, which currently, is to just hardcode the path.