Gnome 3.30 snaps theming issues

Hello snapcrafters, @kenvandine

recently the gnome-calculator snap updated to version 3.30 in Ubuntu 18.04 :dancer: which is great and exactly one reason why snaps are awesome.

One minor issue appeared with this update: the icon used previously the Suru icon for the calculator if Suru icon theme was selected but now it uses the stock adwaita icon: image

Would be great if you’d find time to fix this, it was using the correct icon for several months :slight_smile:

A second issue (that is not directly related to the update) is, that it uses an outdated version of the Yaru/Communitheme theme. It must be several months old (I see this because it uses some old styling we changed) and it would be great if you could update this, too. Other snaps like system monitor, libre office and logs use this outdated version, too.

Best regards, Frederik

I’ll let ken debug the icon issue.

On the theme refresh, a new version in the edge channel for gtk-common-themes is automatically published whenever a new Yaru commit is in master. @kenvandine, @jamesh, I think you are the ones with publisher rights to the stable channel, mind publishing it regularly?



I’ll investigate the icon issue.

We were just talking about what to do about publishing gtk-common-theme. We merged some fixes on Friday but need a way to trigger builds outside of Yaru theme updates.

1 Like

Thanks for the reply!

I wonder what happens in Cosmic when application, cursor and icon theme are all named Yaru (not like 18.04 with the communitheme [old name] snap which uses communitheme/communitheme/suru for application/cursor/icon themes)?
Is there some reference/pointer to the correct name somewhere in the gtk-common-themes snap? Or does it always look for “Suru” for cursor and icon thems?

gnome-calculator 3.30 renamed their icon

it’s “org.gnome.Calculator” now instead of “gnome-calculator”, the snap generated .desktop has a complete path to the icon where it seems he had the name only referenced before (is there a special case for when the snap and icon_name are identical?)

Yeah, that was a fix for the app icon on other distros. I’ll get a proper fix soon. I guess just changing it back to gnome-calculator might get the themed icon.


Looking at the revisions of the snap still on my system, rev 199 has:


And rev 222 has:


The first is a symbolic name that could be overridden by the theme, but will likely not be found if the icon theme doesn’t override it. The second is a full path that will work everywhere but can’t be themed.

To allow reliable theming of snap application icons, we’d want some way for them to install their icon into the hicolor theme (and possibly other themes if they have produced multiple versions) and then that symbolic name in the desktop file. This would also allow the app to provide multiple sizes of their icon rather than having a single version scaled.

A quick sketch of a possible implementation:

  1. snaps can optionally provide a meta/icons subtree that follows the layout of a “base directory” according to the icon theme spec.
  2. when installing or upgrading the snap, snapd will symlink or copy the provided icons into /var/lib/snapd/desktop/icons.

One question we’d need to solve is “what symbolic icon names should a snap be allowed to provide?”. If a snap called gnome-calculator is allowed to provide org.gnome.Calculator, what’s to stop it also replacing the icon for Firefox? But at the same time if we limited the snap to providing names prefixed by the snap name, then icon theme authors would need to override the icon twice: once for the snapped version of the app and once for the regular or flatpak version.


From the Yaru side we changed the shell theme to only use normal icons instead of symbolic icons for the app menu:

Upstream gnome also plans to remove the app menu out of the shell and put it “back” to the applications.

But yes, this is not directly an answer to your question but maybe it’s helpful on some decisions.

I guess I was using the wrong terminology. I was trying to refer to the difference between abstract names like gnome-calculator or org.gnome.Calculator that can pick different images based on theme and rendered size. This was to contrast it to concrete file names like /path/to/gnome-calculator.png that can only ever refer to one image.

I probably should have just said “icon name”.

As for why the change occurred, there is code in Snapcraft to rewrite the icon field of the desktop file. It looks like that should only happen if it already contains an absolute path name though. So it’s not obvious what caused the change.


The gnome-characters snap also uses the adwaita icon. Shall I open another thread for this or could you handle this in this context? Aaaand the gnome-logs application, too :slight_smile: @jamesh

The 3.30 versions of gnome-calculator, gnome-characters and gnome-logs have all been released to stable now and now use the themed icon rather than the application icon.


Awesome! Thank you!


Hmhm this seems to be my current status after refreshing successfully those 4 apps:

gnome-characters & gnome-calculator both updated to 3.29.91 and 3.30 - correct icon everywhere :ballot_box_with_check: gnome-logs updated to 3.30 - old icon in shell - new icon in the app: :crying_cat_face:

gnome-system-monitor updated to 3.30 - old icon in the shell - new icon in the app :crying_cat_face:

I try to reinstall one of the apps and see if this solves those issues

Edit: I tried to refresh from --edge but that were only version downgrades to I went back to stable. I guess I only need to wait some days until the update hits :slight_smile:


Checked again and it is still the wrong icon for gnome-logs and gnome-system-monitor:

Found another minor issue with two of new gnome 3.30 snaps:

gnome-calendar and gnome-contacts 3.30 use the wrong “click” hand when you can click elements and the wrong “increase window size” cursor at the edges of the window:

This should look like this:

This should look like this:

When you press it, the correct picture appears:


@kenvandine @jamesh any update on icon and cursor issues? Would be awesome to have this ready before 18.10 :slight_smile: People already complain about the icon mix, this would reduce it yet a little bit.

We’re still debugging. It’s only an issue when cursor-theme is set to Yaru. If you change it to DMZ-White it’s properly themed.

1 Like

Ahhh okay sorry for the spam!

Maybe there is some relation to the folder hierarchy?

Yaru includes many folders and one is the icon theme including the cursor theme
Unlike other themes which come on their own

Just for general feedback - every icon issue is fixed now

gnome system monitor lacked a symlink in yaru/suru

gnome logs was using the wrong icon

1 Like

I’m with the default theme in Ubuntu 18.04 and I can see no icon for gnome-logs:

This is my info:

$ snap --version
snap    2.35.4
snapd   2.35.4
series  16
ubuntu  18.04
kernel  4.15.0-36-generic

$ snap info gnome-logs 
name:      gnome-logs
summary:   A log viewer for the systemd journal
publisher: Canonical✓


snap-id:      kIMfmZTJspWa8vtfbgU3W9Nbv4V5Qgmh
tracking:     stable/ubuntu-18.04
refresh-date: today at 10:28 CEST
  stable:    3.30.0 (45) 15MB -
  candidate: 3.30.0 (45) 15MB -
  beta:      ↑                
  edge:      3.26.2 (19) 21MB -
installed:   3.30.0 (45) 15MB -