| Summary: | KIconLoader prefers PNG icons over SVG icons | ||
|---|---|---|---|
| Product: | [Frameworks and Libraries] frameworks-kiconthemes | Reporter: | pallaswept <pallaswept> |
| Component: | general | Assignee: | Christoph Feck <cfeck> |
| Status: | RESOLVED FIXED | ||
| Severity: | normal | CC: | akselmo, kde, kdedev, kdelibs-bugs-null, nate |
| Priority: | NOR | ||
| Version First Reported In: | 6.12.0 | ||
| Target Milestone: | --- | ||
| Platform: | Other | ||
| OS: | Linux | ||
| Latest Commit: | https://invent.kde.org/frameworks/kiconthemes/-/commit/4510bba2b31f9346e328ee262c5c42ef5170856c | Version Fixed In: | 6.18 |
| Sentry Crash Report: | |||
|
Description
pallaswept
2025-04-01 12:18:23 UTC
So we can more easily reproduce and investigate this, can you give us an example of an application you have seen this with? Also, can you be more specific about where you're looking at the icon? Is this in the apps menu, on the panel as a shortcut, in the task manager when the app is running, for example? Thanks. Thank you Tracey! > So we can more easily reproduce and investigate this, can you give us an > example of an application you have seen this with? To be very specific, I am mostly testing with CoolerControl: https://gitlab.com/coolercontrol/coolercontrol But I did of course test this with other apps and it's the same for everything I tried. It will work with anything that has an SVG and PNG icons. To select an example from my system, the foot terminal is handy because it only has SVG and a single PNG of 48x48px. I can reproduce by these steps: - In /usr/share/icons/hicolor/ - Rename scalable/apps/foot.svg to foot.svg.0 - Make a duplicate of scalable/apps/gimp.svg - Rename it to foot.svg (now foot should have gimp's icon) - Restart plasma - Foot has foot's icon - Rename 48x48/apps/foot.png to foot.png.0 - Restart plasma - Foot has gimp's icon > Also, can you be more specific about where you're looking at the icon? Is > this in the apps menu, on the panel as a shortcut, in the task manager when > the app is running, for example? All of the above. Icons within the application are not effected, but those in Plasma are subject to this behaviour. The panel icon is configured to use a symbolic icon and only an SVG is created, so I don't observe the behaviour there, but earlier when the symbolic icon was not used, it used the normal icon, and the behaviour was the same in all of the above places. *** This bug has been marked as a duplicate of bug 493034 *** Nate is this a dupe of that? It seems kinda different. I get the same icon everywhere, they get two different ones, they use absolute paths, I don't, they change the desktop file, I don't... Sorry if I'm mistaken about this. Yeah my bad, not the same thing. I tested on git-master, focusing on firefox and pidgin, which have .svg and .png icons and was able to replicate the bug with the Breeze Dark icon theme **Test of renaming the png with Firefox** - Set the bottom panel to 48px, left panel is at 54px - Icon theme was Tela Dark - Renamed /u/s/icons/hicolor/48x48/apps/firefox.png to firefox.png.bak - Copied /u/s/icons/hicolor/48x48/apps/vlc-xmas.png to firefox.png - Restarted Plasma Result: The icon for Firefox showed the Firefox logo correctly - ok - Set the global theme (which also sets the icon theme) to Breeze Dark Result: on the 54px panel the VLC icon is shown instead of the svg Firefox icon - not ok **Test of renaming the svg with pidgin** - Renamed hicolor/scalable/apps/pidgin.svg to pidgin.svg.bak - Copy hicolor/scalable/apps/mpv.svg to pidgin.svg Expect: When pidgin's buddy list is open, the panel icon should be the mpv icon (svg) Result: The pidgin png icon is shown in both panels - not ok Icon loading priorities are in KIconLoader which lives in the kiconthemes framework; moving there. (In reply to TraceyC from comment #6) > I tested on git-master, focusing on firefox and pidgin, which have .svg and > .png icons and was able to replicate the bug with the Breeze Dark icon theme Oh nice one Tracey, thank you! I found it interesting that Tela did not suffer this, at first I thought maybe it was a hint of a workaround. I realised that Tela has a built-in firefox icon. You showed me part of this I had not tested - It will prefer any icon from the current theme, over any icon from the fallback (hicolor) theme, ie PNG(this theme) > SVG(this theme) > PNG(fallback theme) > SVG(fallback theme) Reading it again I can see that, once again, this matches the spec https://specifications.freedesktop.org/icon-theme-spec/latest/#icon_lookup More and more, I feel like this is actually a case of KDE (or is it KF or Qt? I couldn't figure it out) being perfectly compliant with XDG's spec and the spec prefers PNG over SVG. As in, intentional, so not really a bug... Though I'm not sure it was actually the intended result, that SVG icons go un-used. (In reply to Nate Graham from comment #7) > Icon loading priorities are in KIconLoader which lives in the kiconthemes framework; moving there. Thanks Nate! PS sorry to bother you in both issues, I wasn't sure if you would actually get the message from this resolved issue, since I imagine there's a lot of 'noise' in those for you. I hope that wasn't too annoying. Maybe a tiny bit, but by a freak coincidence I had accidentally deleted the email where you first complained that I did it wrong, so getting a second one in the other bug report actually saved me time since I didn't have to go dig around in the trash. :) I need to sit down with the icon spec docs again to confirm what you're saying, but it wouldn't surprise me at all if we're in a state that's "compliant, but not ideal". (In reply to Nate Graham from comment #9) > email where you first complained that I did it wrong Sorry Nate, I really didn't mean for it to come across like that. I think you do a bloody amazing job. It's all right, it was a valid complaint! I really did do it wrong. In KIconLoader::iconPath we have:
```
QString path;
if (group_or_size == KIconLoader::User) {
path = d->locate(name + QLatin1String(".png"));
if (path.isEmpty()) {
path = d->locate(name + QLatin1String(".svgz"));
}
if (path.isEmpty()) {
path = d->locate(name + QLatin1String(".svg"));
}
if (path.isEmpty()) {
path = d->locate(name + QLatin1String(".xpm"));
}
return path;
}
```
So it takes png first. Switching those around might resolve this bug, will try.
I'm curious though why it has been done this way, the git blame doesnt show that far back.
I made a branch for testing my theory https://invent.kde.org/frameworks/kiconthemes/-/commit/c3ed2be285401e263db0ec77e08472394f20258a I haven't been able to repro the bug myself though (In reply to Akseli Lahtinen from comment #12) Thanks Akseli! > I'm curious though why it has been done this way, the git blame doesnt show that far back. I suspect it's XDG compliance: https://specifications.freedesktop.org/icon-theme-spec/latest/#icon_lookup Their pseudocode implementation specifically prefers PNG. To save you the time, one of the two examples: for extension in ("png", "svg", "xpm") { if exists directory/iconname.extension return directory/iconname.extension } So it won't even consider svg unless there is no suitable png found. I seem to remember reading that xdg historically did it that way because svg could be too expensive. Hope that's helpful. Right, this doesn't seem to be a bug per se. The behavior may be undesirable today though. SVG icons are pretty well established throughout the ecosystem, not just in KDE. A possibly relevant merge request was started @ https://invent.kde.org/frameworks/kiconthemes/-/merge_requests/191 Fixed by Akseli Lahtinen with https://invent.kde.org/frameworks/kiconthemes/-/commit/4510bba2b31f9346e328ee262c5c42ef5170856c in Frameworks 6.18. |