Surufy icon script status

Considering some not so precise news got out lately, I’d like to discuss the (real) status of the surufy script.

First of all, I don’t want to create too much expectations, so it won’t be a Surufy script, really.
It is not possible to automatically generate a perfect Suru icon. The script adds a Suru-like tile background (the squircle), with a proper color, behind the original application icon, so that it can look less out of place, but the effect is nice

Builder vlc

The temporary project repository is this one.

The current version is made of the following main files

  • surufy, that contains the functions needed for the job
  •, a script that uses surufy functions and generate one single icon
  •, a script that looks for .png images in /usr/share/icons/hicolor/{size}/apps and generates the correspondent suru icon, saved in $HOME/.local/share/icons/Yaru/{size}/apps'

There are some other details, like how the script skips icons already available in Suru, but are less important in this context. If you run the crawler script today and execute Alt+F2; rt (or just logout/login) you will see the icon set full of Surufied icons, however this is not enough for releasing the package.

Open points

The final script must be automatically executed on each new application install (and uninstall). For example, with APT we need to define a Dpkg::Post-invoke hook, a script that is called after apt-get command. I believe that snap and flatpak have the same or similar concept.


  • APT invokes hooks as root, so the $HOME env is not defined as the user’s home, and the above destination folder cannot be used.
  • snaps and flatpak do not save their icons under /usr/.../hicolor, so even the source folder has to be changed. Moreover, I am not sure whether saving a snap application icon somewhere else will work, considering that the snap is containarized, but I didn’t verify this.
  • If the script was released with Yaru in a snap, it wouldn’t be able to read any folder outside the ones permitted by the container and, more important, could not be installed in the specific APT folder for hooks. This means it must be released as .deb package, that is, separated from Yaru, since Yaru is released also as snap.

Being this the status, it is hardly possible that it will be released in 19.04


  • execute the script automatically at each application install/uninstall (be APT, snap or flatpak).
    • apt: Dpkg::post-invoke script
    • snap hook?
    • flatpak hook?
    • can we execute it on a single icon, in place than calling the crawler?
  • determine a proper destination folder
    • can we use /usr/share/…/Yaru/icons?
  • determine the list of source icon folders, considering snap and flatpak applications as well.
  • package the application as debian package

Thanks for this post!

I think some snaps use even a relative path to an icon like
Instead of
Thus icons in /use/share/icons/current-icon-theme are selected

1 Like

@clobrano, if the full script solution is proving challenging, how about using the version you have to generate some icons for non-snap apps, that we could just commit/push as if we’d drawn them? I really do think the two examples you’ve included here are lovely!

EDIT: In terms of brand, etc., the script approach (whether we do it manually or scriptily) is surely the least controversial thing to do, because it leaves the icon itself unedited. And sticking it on a coloured squircle is no more disrespectful than (e.g.) sticking it on the blue tile in Windows 10.

EDIT 2: The more I think about it, the more I like this idea. it’s surprisingly time-consuming to stick an existing svg on a squircle and agonise for ages about the colour. E.g., I’m doing it with Inkscape, and I still don’t like it as much as the script version. If you ran the script locally and posted the output, we could agree which already look awesome and just commit the pngs into Yaru? We could probably sort a whole bunch of apps in one fell swoop.

1 Like

I could not have said it better @jaggers +1
And if the colored squircle is “too much” change, there’s also the first option we explored with the transparent squircles:

The solution you are suggesting really has the benefit of being a trillion times faster than drawing every icon manually. We could have a squircled desktop from day one.

This would not mean that we can’t still create custom suru icons (in collaboration with the upstream project/dev)


This would be a lot easier for sure, but considering the current hot discussion I would pause a while to think about it in general.

I still don’t think that adding a background would infringe a brand, but we might infringe the desire of the owners. I know that there are tons of icon set out there, but none is the default of a well known and used Linux distribution.

I wrote this in some places now, but I would prefer to contact the maintainers first and see if they like the idea to commit their own version or just discuss the other options.


It’s certainly a hot discussion :slight_smile: but I personally hope we can join the discussion and make some fair points to defend our preferred approach - even as we listen to reasonable points from other people.

One point I’d like to make is that, because of the very nature of how icons work, icon designers don’t control the pixels around their icons, or any that they make transparent. This is just a feature of what icons do. They’re like stickers that get stuck on someone else’s desktop. They can and will end up with anything behind them - even if it’s just the patterns and colours of the desktop wallpaper.

Here’s a non-Ubuntu example. As far as I can tell, in the case of Window 10, the desktop defaults to putting third party icons on blue tiles, because Windows 10 has a visual paradigm where icons are displayed on tiles.

Brand owners can certainly ship an icon for the Windows 10 style and control the tile colour. But, if they just ship an icon with an arbitrary shape and transparent background, I think I’m right in saying it will be put on a square and the square will be blue:


So for me, one part of the protest that I’d really like to challenge is the idea that brand owners wouldn’t be “happy” with their otherwise-unchanged icons being put on coloured squircles.

It’s a shame that an early test screenshot became a focal point for discussion about the script, because the colours were still a work in progress, and a couple hadn’t come out well IMO. But that’s an objection on the grounds of personal taste and aesthetics. If it’s wrong in principle to put an unaltered icon on a coloured squircle - no matter how good we make it look - then I think you could add the same “Would GIMP or Inkscape be happy with this?” caption to the Windows 10 screenshot above.

Also: even if an OS, desktop or theme doesn’t have a unifying device like buttons or tiles or whatever, there will still be the desktop wallpaper. Many OSes and desktops allow icons to be put on the desktop directly, and that means foreign colours and shapes appearing behind icons, and even showing through the transparent parts of them. The default wallpaper for an OS might be horrible for your icon. It might even be a grid of coloured squircles :slight_smile: This is why I say that icon designers can’t control the surrounding pixels or ones they leave transparent. It’s just a feature of icons for them to be stuck on someone else’s desktop, which will have its own theme and visual paradigm.

The other point I’d like to make is that many users simply don’t like the approach where some icons conform to a shape and others don’t. OMG! Ubuntu! didn’t like it, and recently praised the new approach we’re developing. I think the Ubuntu French forum didn’t like the mix either, but I can’t find that post just now. Personally, I think the design of the Suru icons only worked in the original context of Unity 8 because the desktop itself added squircles to all third party icons.

If we’re going to continue using the Suru icons for “house apps”, I think we have to have to find a respectful way of displaying third party icons on squircles, analogous to the way that Windows 10 uses square tiles. In an ideal world, it would be something the launcher and shell do, which is how it works in Unity 8 and Windows 10 (because I very much doubt someone at Microsoft is adding blue squares in Inkscape, lol). But I think Ubuntu has to do it, or accept that Suru isn’t the right icon set for Ubuntu’s new Gnome desktop.

If, instead, we display the house apps as logos on squircle-shaped buttons, and gently encourage app maintainers to provide an icon in the same style - but only if they want - then the end result will always be a mix of uniform versus non-uniform icons, which too many users dislike. Sadly, I think the same is true if we reach out to maintainers one at a time and ask for permission to make a Suru icon on their behalf.

So: my favourite approach is for Ubuntu to have a shell and launcher that display non-squircle icons in front of a squircle, so third party icons can be completely unchanged but still look good next to Suru ones. My second favourite approach is to include a script that simulates this behaviour.

My third favourite approach is to manually simulate it for some of the most popular apps, again without actually changing the logo graphic at all. And my fourth favourite approach is to switch to a nice icon theme for the default apps that doesn’t use a uniform shape.

My least favourite approach is to use icons of uniform shape for the very small number of “house apps”, and simply hope that we can persuade app maintainers to accept or ship an icon in the same style.

Lastly, one point I hope we can agree on, among ourselves at least: Ubuntu, Yaru, and many Ubuntu users want a Linux ecosystem where distros (including Ubuntu) can have their own visual identity.

Some of the people participating in this debate don’t share that view and have come round to the idea that “themes” are not good. That’s a valid opinion that people hold for considered reasons, but it means we can’t expect everyone to see 100% eye-to-eye on Yaru, even if we find the area with the most common ground. In those cases, we won’t be able to convince everyone that Yaru’s approach is good, but I hope we can at least make the point that it’s permissible (in the spirit of open source, forking, etc.) and respectful to brand owners (comparable to how icons are treated in other OSes and in the spirit of how icons can be used cross-platform).