Gnome snaps in 19.04

@willcooke @jamesh @kenvandine

Hello everyone,

last week an update hit disco daily, where gnome-calculator, gnome-system-monitor, gnome-logs and gnome-characters .deb’s where exchanged with snaps - which is generally an awesome idea to receive the latest update of those apps!

Sadly those apps ship with the upstream icons and not with the Ubuntu/Yaru icons. We - especially our icon specialist @jaggers - spent a lot of time in the last cycle on making the new icons look good and providing a complete yaru/ubuntu icon grid look.

I understand that snap’s are the main focus of Canonical.
From the point of view of the yaru design team I wonder if it would be possible to “bake in” the Yaru icons into those snaps instead of the upstream ones since they really “ruin” the hard work we have done in the past/current cycle and additionally the Ubuntu dock default icon size is 48px but the new gnome icons are optimized for 2^n px (…16,32,64…). So the result is a really heavily blurred icon on the launcher. This does not happen with the Yaru icons because they are exported PNGs, optimized also for 48px.

This is the github issue

Best regards, Frederik


[sorry for the delay – I didn’t have posting privileges for this part of the site before]

So I put together a proposal for how snapd could support icon themes here:

I believe this would satisfy the problems you’ve identified by letting a snap application define and use a named icon for its .desktop file.

I’m a little bit wary of e.g. letting the gnome-calculator snap define an org.gnome.Calculator icon name though: if it could define an icon with that name, what’s to stop it replacing the Chromium snap’s icon, or some application from the host system.

That’s why I’ve proposed restricting icons to match snap.${SNAP_NAME}.*. I realise this is not ideal for reusing icons in existing themes, but it would allow Yaru to override the snap icons through appropriate symlinks.


As far as I know, this is a problem we have with .deb applications as well. Taking the same example, there are many themes that redefine Chromium icon and the distro uses the theme’s icon, not the official Chromium’s one

Right, but .deb packages run arbitrary shell scripts as root during install. They can literally do anything to your system. That’s why the only configured sources on a fresh install provide packages from trusted Ubuntu developers.

One of the goals of snapd is to get to a point where users can be reasonably confident that installing an application won’t interfere with the host system or any other snaps installed on the system. So my proposal attempts to solve the problem while not walking backwards on snapd’s other design goals.


I understand. So, from one side, there’s the owner’s right to ship with a specific icon and on the other side the habit of theming everything in a linux system :slight_smile:

Would it be possible to design an override property for the icon shipped with a snap? So that if override is true, the theme icon would be used (if available) and it is impossible otherwise?

EDIT: or even better, I should discuss on the original link :smiley:

You would still be able to override the icons. As a concrete example, gnome-calculator might ship the following in it’s snap:


… and the .desktop file might have the following:


If the Yaru theme provided 48x48/apps/snap.gnome-calculator.calculator.png, this would override the icon provided by the snap.


If it helps: we can provide any symlink that helps. That’s really no problem at all and 5 mins work

calculator-app ->
snap.gnome-calculator.calculator and so on :slight_smile:

And thank you very much for working on that!


@jamesh could you write here all the proposed symlink names for


please :slight_smile:

1 Like

Sorry, I missed your reply here. It is too early to provide that information:

  1. we don’t yet have consensus on the icon theme support proposal.
  2. the exact icon names would also depend on the individual snaps. The proposal only mandates a prefix for the snap’s icon names: the rest of the icon name is at the snap author’s discretion.

I am working on a proof of concept implementation of my proposal though, so hopefully we’ll have something concrete to test sooner rather than later.


For what it is worth, the icon theme support got merged into snapd a few weeks ago:

This should make it into snapd 2.42, which is currently in beta. This won’t change how any existing snaps work, even with a rebuild. We should be able to start experimenting with some of the Canonical managed snaps though, once 2.42 is generally available.