Summary: | Obeying icon themes' fallback icon themes causes inconsistent icons | ||
---|---|---|---|
Product: | [Frameworks and Libraries] frameworks-kiconthemes | Reporter: | firewalker <firew4lker> |
Component: | general | Assignee: | Carl Schwan <carl> |
Status: | REOPENED --- | ||
Severity: | normal | CC: | aloisio, carl, fabian, firew4lker, KDE, kdelibs-bugs, locutus, markovs.i.mail, nate, nicolas.fella, notmart, pranav.3943, sunny.bed7466, voron1, Wi11iam_1 |
Priority: | VHI | Keywords: | regression |
Version: | 5.96.0 | ||
Target Milestone: | --- | ||
Platform: | Arch Linux | ||
OS: | Linux | ||
See Also: |
https://bugs.kde.org/show_bug.cgi?id=446477 https://bugs.kde.org/show_bug.cgi?id=476084 |
||
Latest Commit: | https://invent.kde.org/frameworks/kiconthemes/commit/13181b03eac3c85f0649d5399d8c3037c388928c | Version Fixed In: | |
Sentry Crash Report: | |||
Attachments: |
Wrong icons sourrounded in red
I confirm that frameworks 5.89 does not solve the bug Buggy icons (left) and correct icons (right) |
Description
firewalker
2021-11-20 11:59:51 UTC
To fix this, did you revert just kiconthemes, or breeze-icons too, or all frameworks? *** Bug 445811 has been marked as a duplicate of this bug. *** (In reply to Nate Graham from comment #1) > To fix this, did you revert just kiconthemes, or breeze-icons too, or all > frameworks? Just kiconthemes. I think the following commit causes the issue. I will test it and report back. https://github.com/KDE/kiconthemes/commit/de3a1abb1839136322f32f2782f9592280b2bbd3 Thanks, that's very helpful. Can confirm. I've left a comment at https://invent.kde.org/frameworks/kiconthemes/-/merge_requests/45 A possibly relevant merge request was started @ https://invent.kde.org/frameworks/kiconthemes/-/merge_requests/49 Created attachment 143966 [details]
Wrong icons sourrounded in red
I have exactly the same problem on KDE Neon after the updates I've done on the last Saturday (as shown on the attached file).
Git commit 13181b03eac3c85f0649d5399d8c3037c388928c by Nicolas Fella, on behalf of Jan Blackquill. Committed on 03/12/2021 at 11:20. Pushed by nicolasfella into branch 'master'. KIconLoader: prefer icons from current theme before falling back to other themes M +25 -0 autotests/kiconloader_unittest.cpp M +7 -27 src/kiconloader.cpp https://invent.kde.org/frameworks/kiconthemes/commit/13181b03eac3c85f0649d5399d8c3037c388928c Can this be related to the fact that in plasma 5.23 my icons do not respect the themes "inherits=hicolor, breeze" path anymore? for example the icon for Steam used to come from the hicolor theme (where steam installed it) before as it is the first in the inherits chain, now it comes from the breeze theme... (it even comes from breeze theme if it is completly removed from the inherits) Idk if this belongs here but shouldnt that be considered undesired behaviour? i want my inherits chain to work as before and not use breeze icons when they are available in hicolor... Please don't re-open the bug unless you've verified that the fix in Frameworks 5.89 isn't working for you. Also, that issue seems like it could be unrelated. Is your icon theme set to Breeze? If so, then what you're describing is behaving as intended; the system will pull icons from your chosen icon theme before that icon's fallback theme or hicolor. sry didnt mean to cause confusion: i created a new ticket here: https://bugs.kde.org/show_bug.cgi?id=446477 5.89. doesn't fix it for me. The only way to fix it is for me to remove the line addThemeByName(QIcon::fallbackThemeName(), appname); from kiconloader.cpp and rebuild. Created attachment 144662 [details]
I confirm that frameworks 5.89 does not solve the bug
I don't think this should be considered as a bug. Before that change, we were ignoring the fact that many apps and framework were setting a fallback icon theme and now we are just obeying this fallback instead of returning an empty icon. The issue here is that apps have no way to communicate when not showing an icon is fine or when it will breaks (e.g. icon only buttons). And I'm not sure this is fixable. It isn't like there isn't an icon for the application to choose from and doesn;t show anything. Maybe something else is forcing the app to choose the fallback theme instead the next relative icon? Application that comes with their own icons will choose something else. E.g. Clementine. Will choose /usr/share/icons/breeze/apps/48/application-x-clementine.svg Instead of /usr/share/icons/hicolor/64x64/apps/org.clementine_player.Clementine.png Created attachment 144706 [details]
Buggy icons (left) and correct icons (right)
@ Carl Schwan - I can't agree... Until a few weeks ago we had a consistent icon theme (and on the computers using older version of frameworks, we still do, as you can see on the right panel of my attachment, a screenshot I took on my laptop running under Kubuntu)... Now we don't have (as you can see on the left panel of my attachment, my desktop PC running under KDE Neon; the icon changes are marked with red arrows)... It's definitely a bug, or at least a horrible regression... And apparently all it takes to fix it is changing one line of the code...
*** Bug 447378 has been marked as a duplicate of this bug. *** *** Bug 447092 has been marked as a duplicate of this bug. *** Bug 448248 - possibly a duplicate qBittorent provides "qbittorrent-tray-light", "qbittorrent-tray-dark", "qbittorrent-tray" and "qbittorrent". Breeze provides only "qbittorrent", but it is enforced in all cases, even if app or desktop entry have other one configured (like qbittorrent-tray-dark). It's not entirely clear to me which of the reported issues are about the original bug or a regression caused by 13181b03eac3c85f0649d5399d8c3037c388928c. (In reply to Konrad Materka from comment #18) > Bug 448248 - possibly a duplicate > > qBittorent provides "qbittorrent-tray-light", "qbittorrent-tray-dark", > "qbittorrent-tray" and "qbittorrent". Breeze provides only "qbittorrent", > but it is enforced in all cases, even if app or desktop entry have other one > configured (like qbittorrent-tray-dark). This is definitely an effect of 13181b03eac3c85f0649d5399d8c3037c388928c. In openSUSE we also have negative effects of this: https://bugzilla.opensuse.org/show_bug.cgi?id=1195551 Package patterns have icons like "pattern-kde-devel", but with this change applied those fall back to "pattern.svg" provided by breeze as the "generic" variant. FWICT, this is in accordance to https://specifications.freedesktop.org/icon-naming-spec/icon-naming-spec-0.8.html#guidelines, but apparently many icons were not named with this in mind. I just want to mention that bug https://bugs.kde.org/show_bug.cgi?id=447092 is marked as duplicate of this one, but I'm not sure if they're really related. Anyway I want to highlight that google chrome web application icons are still broken With the last update (frameworks 5.90) it's getting much better, but still not perfect... I have recovered correct icons for Models (a directory in the home folder), recent places (in the Discover sidebar), the system drive (in the Discover sidebar), MP3 files, but XLSX files for example still have a wrong Breeze icon (the same for the application launchers for all the apps in the LibreOffice suite)... There is also a weird Breeze icon for "sort by" button in Discover. Still present in 5.92.0 Still present in 5.93.0 Still present in 5.94.0 Still present in 5.95.0 Still present in 5.96.0 Still present in 5.98.0 Still present in 5.99.0 Still present in 5.100.0 It's a very sad list we have here... "Still present in" and all the new versions spanning for last eight months... As if no one was willing to correct this bug anymore... Use Breeze icons or suffer visual inconsistencies... A bit sad for what is otherwise really the best Linux desktop environment, renowned for its adaptability to users' needs, preferences and tastes... Still present in 5.101.0 |