Not re-coloring icons in Discover when COSMIC theme is selected

[adil192]

I was testing cosmic's qt theming today and found my Discover store is unthemed: it's not following my theme's green colors and has dark-on-dark icons.
After compiling and reinstalling cutecosmic from source, Discover got themed, but the icons were still dark-on-dark.

It could also be a conflict between cutecosmic and my recently merged qt styling in libcosmic pop-os/libcosmic#1121. If so, I'd like to fix it.

Behaviour:

• cutecosmic inverts the icons of Ark but not Discover. cutecosmic is using the COSMIC icons since that's what I've got in my system settings.
• qt6ct doesn't invert anything but switches between breeze and breeze-dark icons.
• If either breeze or breeze-dark are selected in system settings, cutecosmic correctly inverts them when necessary. But it can't invert COSMIC/Pop/GNOME icons (except in Ark.)

Screenshots

QT_QPA_PLATFORMTHEME="cosmic" ark:

QT_QPA_PLATFORMTHEME="cosmic" plasma-discover:

For reference, this is the pop-os/libcosmic#1121 qt6ct theme which uses breeze and breeze-dark icons for light and dark themes respectively.

QT_QPA_PLATFORMTHEME="qt6ct" plasma-discover:

Package versions

I'm using these packages from Fedora:

• ark: 25.12.2-2.fc43
• breeze-icon-theme: 6.23.0-1.fc43
• cutecosmic-qt6: 0.1^git20251110.1469fa3-1.fc43
• plasma-breeze: 6.6.0-1.fc43
• plasma-discover: 6.6.0-1.fc43
• qt6-qtbase: 6.10.1-3.fc43

Qt libs

Ark appears to be using the same qt libs as Discover.

ahann@fedora:~$ ldd /usr/bin/ark | grep Qt
	libQt6Widgets.so.6 => /lib64/libQt6Widgets.so.6 (0x00007f6de1a00000)
	libQt6Gui.so.6 => /lib64/libQt6Gui.so.6 (0x00007f6de0e00000)
	libQt6Core.so.6 => /lib64/libQt6Core.so.6 (0x00007f6de0600000)
	libQt6DBus.so.6 => /lib64/libQt6DBus.so.6 (0x00007f6de0d25000)
	libQt6Network.so.6 => /lib64/libQt6Network.so.6 (0x00007f6ddfa00000)
	libQt6Xml.so.6 => /lib64/libQt6Xml.so.6 (0x00007f6de182a000)
	libQt6PrintSupport.so.6 => /lib64/libQt6PrintSupport.so.6 (0x00007f6ddf980000)
	libQt6WaylandClient.so.6 => /lib64/libQt6WaylandClient.so.6 (0x00007f6dde254000)
ahann@fedora:~$ ldd /usr/bin/plasma-discover | grep Qt
	libQt6WebView.so.6 => /lib64/libQt6WebView.so.6 (0x00007f3bb5c21000)
	libQt6Widgets.so.6 => /lib64/libQt6Widgets.so.6 (0x00007f3bb5200000)
	libQt6Quick.so.6 => /lib64/libQt6Quick.so.6 (0x00007f3bb4a00000)
	libQt6Qml.so.6 => /lib64/libQt6Qml.so.6 (0x00007f3bb4200000)
	libQt6Gui.so.6 => /lib64/libQt6Gui.so.6 (0x00007f3bb3600000)
	libQt6DBus.so.6 => /lib64/libQt6DBus.so.6 (0x00007f3bb40a3000)
	libQt6Core.so.6 => /lib64/libQt6Core.so.6 (0x00007f3bb2e00000)
	libQt6QuickControls2.so.6 => /lib64/libQt6QuickControls2.so.6 (0x00007f3bb2de8000)
	libAppStreamQt.so.3 => /lib64/libAppStreamQt.so.3 (0x00007f3bb2d19000)
	libQt6Concurrent.so.6 => /lib64/libQt6Concurrent.so.6 (0x00007f3bb51f5000)
	libQt6Network.so.6 => /lib64/libQt6Network.so.6 (0x00007f3bb2000000)
	libQt6QmlMeta.so.6 => /lib64/libQt6QmlMeta.so.6 (0x00007f3bb2c7a000)
	libQt6QmlModels.so.6 => /lib64/libQt6QmlModels.so.6 (0x00007f3bb1ed3000)
	libQt6OpenGL.so.6 => /lib64/libQt6OpenGL.so.6 (0x00007f3bb1e23000)
	libQt6Xml.so.6 => /lib64/libQt6Xml.so.6 (0x00007f3bb268d000)
	libQt6QuickTemplates2.so.6 => /lib64/libQt6QuickTemplates2.so.6 (0x00007f3bb0600000)
	libQt6QmlWorkerScript.so.6 => /lib64/libQt6QmlWorkerScript.so.6 (0x00007f3bb0937000)
	libQt6WaylandClient.so.6 => /lib64/libQt6WaylandClient.so.6 (0x00007f3bac6d7000)
ahann@fedora:~$ strings /lib64/libQt6Core.so.6 | grep "Qt 6"
Qt 6.10.1 (x86_64-little_endian-lp64 shared (dynamic) release build; by GCC 15.2.1 20251211 (Red Hat 15.2.1-5))
QMetaObject::indexOf%s: argument "%s" is not normalized, because it contains "QVector<". Earlier versions of Qt 6 incorrectly normalized QVector< to QList<, silently. This behavior is deprecated as of 6.10, and will be removed in a future version of Qt.
ahann@fedora:~$

[IgKh]

Thanks for raising the issue!

First, to align on what (to my understanding) is the correct terminology and context: the icon engine component of CuteCosmic does not invert icons, per se. What it does do is to re-color symbolic icons (SVG icons that consist only of outlines with no colors or fills, more or less) according to theme colors. Importantly, it does not affect full-color icons at all; this is in line with other toolkits across the Linux desktop.

Symbolic icons are very popular in recent years, and both Breeze and COSMIC icon sets consist of many of them. The problem is that they are not standardized at all. I.e. there are two different ways to even recognize a given SVG icon as symbolic:

1. The iced/Gtk way - the icon's name ends with -symbolic (or -symbolic-rtl or other such variation)
2. The KDE way - the icon doesn't need to be named in any particular way but its' SVG source contains a special placeholder style tag.

There are even more ways to actually perform the re-coloring:

1. In iced/libcosmic: Just tinting every pixel of the icon post-rendering with a theme foreground color.
2. In KDE: injecting a CSS block defining the colors into the said placeholder tag prior to rendering.
3. In Gtk: a more elaborate transformation of the SVG source based on well-known class attribute values.

For matching L&F of the COSMIC Desktop, and in an environment where icons for a KDE/Qt application may come from a mix of a COSMIC or Gtk oriented theme and a Breeze fallback - CuteCosmic detects symbolic icons based on both approaches, and re-colors with the iced approach.

(There was some effort in the past to standardize this - e.g. here and here that didn't seem to go anywhere)

Now for the crux of the matter:

There is actually a very significant difference between Ark and Discover: Ark is a Qt Widgets application, while Discover is a Kirigami application (you can see that it also links to QML and Qt Quick). Application authors always have the last say in Qt when it comes to styling, but Widgets applications normally use the regular Qt APIs (e.g. QIcon::fromTheme) that interact with a Icon Engine installed by a Platform Theme plugin. "Vanilla" Qt Quick is the same.

Kirigami however appears to have its' own Icon component, that uses a different and unique platform abstraction plugin to load icons. Such a platform plugin is loaded along with KDE's qqc2-desktop-style Qt Quick style engine, and it uses KDE Framework APIs for loading icons, bypassing CuteCosmic's icon engine entirely (but still querying it for the icon theme names). Said APIs are only aware of KDE's way of defining and processing symbolic icons, so if a symbolic icon from the COSMIC theme ends up being loaded - they can't and won't re-color it so it appears as a dark-on-dark shadow. (For some reason this also happens to Breeze symbolic icons that are loaded from a fallback chain).

You can set a regular Plasma session to use the COSMIC icon theme, and you'll see the same and worse.

I think this should be solvable by somehow integrating with Kirigami, but I'll need to search for a good way to do so. Going back to forcing all Qt apps to use only Breeze icons is kinda lame I think, choice of an icon set is a very personal thing to many people.

It could also be a conflict between cutecosmic and my recently merged qt styling in libcosmic pop-os/libcosmic#1121. If so, I'd like to fix it.

No, it is not related. When CuteCosmic is active, it generates its' own KDE color file from the COSMIC theme, and applies it so it is isolated from the theme selection in KCM. This is specifically done to not clobber unrelated KDE settings.

[adil192]

Thank you for your attention to the matter, and for the explanation. I'm now seeing why kde union is getting so much attention!

Going back to forcing all Qt apps to use only Breeze icons is kinda lame I think, choice of an icon set is a very personal thing to many people.

100%. I wanted to avoid the dependency on breeze in my qt theme, but was forced to because of dark-on-dark icons.

No, it is not related. When CuteCosmic is active, it generates its' own KDE color file from the COSMIC theme, and applies it so it is isolated from the theme selection in KCM. This is specifically done to not clobber unrelated KDE settings.

Something peculiar is happening here then: you can see in e.g. pop-os/libcosmic#1128 that cutecosmic is somehow inheriting the KColorScheme or qt6ct's colors.

But I'm glad to hear it's not related / that I've not broken anything. I was worried since Discover is one of the apps in cutecosmic's README.

In this case, feel free to close this issue or keep it open to track Qt Quick icon support :)

[Tenshou170]

From my own private experiment, I was also facing problems with theming the icons and making it properly use the default Pop/Cosmic icon rather than defaulting to Breeze icon. The Kirigami apps in particular are problematic to make them use tinted/dark-light symbolic variants of the icons, while it's somewhat doable with standard Qt apps.

I have little to no knowledge for Kirigami frameworks, so yeaaaaaah....

[IgKh]

I've been having a discussion with the KDE team on this topic, under https://invent.kde.org/frameworks/qqc2-desktop-style/-/work_items/16.

The Union output for Qt Quick will have a proper abstraction for platform theme plugins for affecting icon loading and colors. My intention is to ship such a plugin with CuteCosmic after Union becomes generally available. In the short term - for qqc2-desktop-style, there may be possible to add a specific workaround to it that will make it use CuteCosmic's icon loader, although with somewhat diminished functionality.

[IgKh]

A workaround for qqc2-desktop-style was merged upstream, and I've added code to enable the workaround into CuteCosmic. It will need KDE Frameworks 6.29 probably, expected in mid August. I'll tag a release after that.

This is still only a half-measure; there are still some gaps in Kirigami applications. For example, if you have a dark theme but with a very contrasting accent color, the icon on a highlighted list entry is not very visible. This will be solved longer term with a Union platform plugin.

Speaking of which, I've started some experimentation with Union as shipped with KDE Plasma 6.7; there are still several roadblocks in providing a COSMIC-specific platform plugin for it. I'll take it up with upstream.