update adwaita-icon-theme to 44.0

If we are trying to be 100% backwards-compatible, then what we would need to do is:

generate a set of icons that existed (at any size) in 43, e.g. Adwaita/16x16/devices/input-gaming.png becomes input-gaming and Adwaita/48x48/devices/audio-headset-symbolic.symbolic.png becomes audio-headset-symbolic
generate the corresponding set for 44
compare the two sets
if an icon has disappeared, assess (e.g. via codesearch) whether we can safely remove it, or whether we need to ship it (for example by stealing it from an older icon theme) for backwards compat with packages elsewhere in Debian
if an icon still exists, no problem
if an icon is new in 44, no problem

debdiff is less useful for this, because it doesn't know that (for example) we can use a 24x24 icon as a blurry fallback for a 48x48 icon of the same name.

I thought I'd already written a script to do this comparison, but it doesn't look like I did.

For instance, looking at the debdiff, I think we have lost application-certificate, but maybe there's still a different sized version of it that I'm not seeing.

There is also an argument to be made that random third-party packages shouldn't be relying on adwaita-icon-theme having some specific set of icons in it, and if a package needs an icon then it should be providing it itself (e.g. as a GResource); and the beginning of the trixie cycle is an ideal time to break other packages, while they have the whole rest of the cycle to catch up. Indeed, if we want to drop some or all of the v41 icons too, now would be the time to do it.

I think maybe a good compromise would be to generate the list of icons that disappeared between 43 and 44, and commit it in debian/, but if the list isn't too long, not immediately fill in the gaps?

Initially uploading to experimental rather than straight to unstable would probably also be a good idea.

In this release, many full-color icons are only supplied as 16x16 and scalable. We supply 24x24 and 48x48 icons for our legacy 41 icon set. Does it make sense to switch those to 16x16 too? On the other hand, there were changes made to some of the 16x16 icons in the 44.0 release to ensure that those look good; that work was never done for the 41 series.

My understanding is that if the theme ships 16x16 and scalable, and the application asks for a 48x48 icon, what it will get is the scalable icon scaled down to 48x48.

For the legacy 41 icon set, shipping 24x24 and 48x48 was a compromise, to minimize the cost of shipping the legacy icons without breaking apps too badly. I didn't want to ship the big versions like 96x96 or (worse) 256x256, because they cost a lot of installed size (5M according to the changelog). I also didn't want to ship too many smaller versions, because those cost multiple MB too, and applications that want a 16x16 icon can always scale down from the 24x24 one. The quality might be lower, but apps affected by that are very welcome to ship their own better version.

When applications ask for an icon larger than 48x48, what they get is a blurry upscale of the 48x48 version, which looks bad, but should still be recognisable. Again, apps affected by that are very welcome to ship their own better version.

I think we would not want to ship 16x16 only, because scaling that up to 48x48 or more is going to look awful, and potentially doesn't have enough detail to even recognise what the icon is meant to be.

We can use debian/icon-viewer.py to get an idea of how bad things look.

Yes, it looks like the non-symbolic version of application-certificate has disappeared. That may be unintentional since I believe upstream doesn't have that kind of script either.

build log

merged

I've uploaded 44 to experimental with no legacy icons at all, but I suspect that might not be what we want in the long term. We might also want to skip past 44 to 45~beta, to bring back a few of the missing icons, but I haven't done that just yet.

The problem with shipping any legacy icons at all is that upstream has changed the index.theme so it only has 16x16 bitmaps, and scalable icons. That means that any time we ship a legacy icon (which typically don't provide a scalable version), our only simple options are to make it 16x16, or to patch the index.theme to re-introduce additional icon sizes.

I tried the "16x16 only" route, but several apps on my laptop are relying on icons from the theme as their app icon, which makes them blurry and awful when I do that.

If I drop the legacy icons completely, most of them use the symbolic icon instead, and those are fine (in general) - although "Package Updater" (gnome-package-updater) gets a default icon, and "Packages" (gnome-packagekit) gets an outline of a box, which I can only recognise because I already know what it's meant to be. I think as a minimum we need to get both of those shipping their own unique icon, probably by copying it from old Adwaita and renaming it to their app ID.

One other thing that might be an option is to introduce a new Adwaita-legacy theme directory which has the legacy icons from v41, and give Adwaita Inherits=hicolor;Adwaita-legacy;? I think that would mean icons would be searched in hicolor (fixing #1022221) before searching in Adwaita-legacy.

update adwaita-icon-theme to 44.0

Merge request reports

Activity