Created attachment 145273 [details] Comparing 5.87 and 5.90 with Breeze themes SUMMARY Since breeze-icons 5.88, the places icons have a white foreground for "Breeze Dark". The contrast clashes with the folder background. The icons display as expected under the "Breeze" and "Breeze Light" theme. #b0ddf5 (foreground) on #3daee9 (background) for the default KDE blue does not meet accessibility contrast standards: https://contrastchecker.com/ making it harder for visually impaired users. The icons at /usr/share/icons/breeze-dark/places/48/ represent the correct colour. They appear to be the same for "breeze" too. It's confusing because: - The user doesn't know where this foreground colour is coming from. - Not clear if this foreground colour can be changed. - If the foreground contrast is supposed to be handled automatically or if this was intentional for Breeze Dark. A temporary workaround is to downgrade breeze-icons to 5.87. STEPS TO REPRODUCE 1. Create a new user profile, with default theme/icon settings (Breeze Light) 2. Open Dolphin, observe correct icon colour. 3. Change theme to "Breeze Dark" and observe icons again. OBSERVED RESULT The foreground for the icon within the icon (e.g. Documents, Downloads, Music) is insufficient (#b0ddf5). The Icon chooser (such as when changing a folder's icon) shows the darker, original contrast (#366681), which is inconsistent with what actually gets displayed in Dolphin. EXPECTED RESULT The foreground is the same as Breeze Light (#2e5d77), and previous <=5.87 versions. SOFTWARE/OS VERSIONS OS: Arch Linux KDE Plasma Version: 5.23.5 KDE Frameworks Version: 5.89.0 Qt Version: 5.15.2 ADDITIONAL INFORMATION - Colour hex codes in this report were provided as a rough indicator. - Local cache was cleared (~/.cache) when testing.
I tried looking into this, but I'm stumped. A git bisect between v5.87.0 and v5.88.0 reveals that 1b92cfc450f6ab6b72ed9ef69c052e4624e5a040 ("Remove exact duplicate icons from dark theme") was the first commit to introduce the issue, but it seems like something else is involved. If the change was intended to deduplicate icons from the source and so dark coloured themes use lighter monochrome icon colours (like toolbars, menus), it kind of makes sense - this bug would be about the wrong monochrome colour being used/forced inside a folder icon when dark colour scheme like Breeze Dark is set. Some questions to help understand the situation: - Where's the code that changes the behaviour when a dark colour scheme is selected? - Why would icon previews in the icon picker (32px) show the original icons, but Dolphin renders modified icons? - Why would places icons (32, 48, 64, 96) in /usr/share/icons/{breeze,breeze-dark} be exactly the same? - Can this be disabled (at build, env variable, hidden config file)? Possible guesstimate solutions: - Skip processing places icons over 32px? - Add a checkbox in System Settings' Icons or Colours tab to set icon foreground to dark/light?
There is a workaround, thanks to clues in BUG 353819. > Why would places icons (32, 48, 64, 96) in /usr/share/icons/{breeze,breeze-dark} be exactly the same? There's CSS in the icons that look for "current-color-scheme" and recolours them accordingly. Still not sure which component (KIO, KIconThemes?) actually does the processing. Removing this ID from the SVG prevents them from being recoloured. Potentially, further optimisation could deduplicate these further if they are byte-for-byte the same, so Breeze-Dark can fallback to Breeze. > Can this be disabled (at build, env variable, hidden config file)? Not that I could see with toggles, but this can be patched out when building the package: find . -name "*.svg" -exec sed -i 's/current\-color\-scheme//g' {} + Unrelated: I'm also patching out the 96 icons locally, as they've become a tad bit thinner since 5.87 that I'm struggling to see some of these icons (e.g. downloads, templates) at a distance. (4K display, X11 user here) find . -type d -name 96 -exec rm -vr {} +
*** Bug 466912 has been marked as a duplicate of this bug. ***