Snappy and system's Icon themes


#1

Please, when snap packages will using system icon themes? It should be easy to change (probably) because all what I need to do (as workaround) is that I change “Icon” absolute path to just application name.

Here is a example:

cd /var/lib/snapd/desktop/applications/
nano spotify_spotify.desktop

And in editor I change

Icon=/snap/spotify/34/usr/share/spotify/icons/spotify-linux-128.png

to

Icon=spotify

But I need it to every new package which I install. It’s a chance to fix it please? Thank you very much

Best regards


#2

It’s currently not possible as the snaps’ icon(either $SNAP/meta/gui or $SNAP/{,usr/}share/icons) isn’t in the search paths of the Icon Theme Specification, the only way to ensure that the snap’s menu entry has an icon is to hardcode it.

If we only specify icon name then the menu entry will have no icon if there’s no icon theme provide it.


#3

we can do it by adding icon file to /usr/share/pixmaps with the same name like in this case sportify.png. I replace the icon in desktop file and created icon in /usr/share/pixmaps it is working fine with user themes as well as system themes


#4

I put together a proposal for a way to handle this:

With this proposal, an application would be able to provide multiple images for their icon (different sizes, ones to match existing themes, etc), and by using icon names it would be possible for themes to override a snap’s icon. I don’t know how safe it would be to let the Spotify snap claim the spotify icon name though: I think we need some namespacing to prevent snaps treading on each others’ toes, or interfering with the host system.


#5

if snaps are going to be using unexpected icon names like snap.gnome-calculator.calculator is there going to be a list made somewhere to allow icon theme makers to create the symlinks to the expected icon names like calculator.png ?

Think it would be a bit much to expect every icon theme maker to download and install every snap to find out what the icon names are! Otherwise the proposal as intimated will not help the “the icon is broken” claim by end users.


#6

Note that I’ve done zero implementation work at this point: the proposal is all that there is. I wanted to explore how we could interface with the existing icon theme system, and what constraints would be needed to prevent interference between snaps.

At present, that means using the snap name as a namespace qualifier. I agree that it’d be nice to be able to claim other namespaces. For modern desktops it is common for an app to use the same reversed DNS name as a prefix for icon names, desktop file IDs, D-Bus well known bus names, etc. I agree that it would be nice if a snap could claim such a prefix (maybe reuse common-id?) and have snapd prevent other conflicting snaps from being installed, but that infrastructure isn’t there now.


#7

thank you for your proposal. I want to ask i question. when we put image of 16×16 icon folder it start to deform as we increase size of icons but this will not happen when we use icon of 64×64 and decrease icon size so my question is why don’t we use icon of big size or why do we use icon for different icon sizes and not one with big size? I know multiple feature uses multiple icon sizes but they can use the large icon like 256×256.


#8

Escape asterisks by prefixing them with a backslash (\*)


#9

The icon theme’s index.theme file describes how the images in various directories are used. I’d suggest consulting the icon theme spec for details. It’s possible the two directories have different scaling modes set.


#10

I edited it to use ×s instead of *s :slight_smile: