Bug 451538

We're using a custom contentItem for this ToolButton, and it uses a Kirigami.Icon for the icon. The issue is that Kirigami.Icon assumes that an icon ending with -symbolic or -symbolic-rtl is a monochrome icon that needs to be recolored and made monochrome.

This kind of needs to be discussed and fixed in Kirigami IMO, because that doesn't seem like it's the safest assumption. There is in fact an open merge request relating to this (https://invent.kde.org/frameworks/kirigami/-/merge_requests/511) but in its current form, it actually makes the situation worse for me, not better. Hopefully that'll get fixed.

In the meantime, I can change the icon name to omit -symbolic.

Git commit b579a5d94a3afbd6f85a95cf368a29e8c96c2b92 by Nate Graham.
Committed on 26/03/2022 at 15:01.
Pushed by ngraham into branch 'Plasma/5.24'.

Don't let back arrow be re-colored to monochrome

The back button uses a custom content item with the icon being provided
by Kirigami.Icon. Unfortunately, Kirigami.Icon currently suffers from an
issue that causes colored icons that end with "-symbolic" to be forced
to monochrome. See https://bugs.kde.org/show_bug.cgi?id=451538.

There is an open merge request to fix that
(https://invent.kde.org/frameworks/kirigami/-/merge_requests/511), but
the fix is in Frameworks, which means it will only get to people who use
rolling release distros or whose packagers backport the fix.

This commit targeted at the Plasma/5.24 branch only is a local
workaround intended to alleviate the situation for LTS distro users who
are less likely to get the frameworks fix, once it's merged. The master
branch doesn't need the workaround since we can hope  that the
Frameworks fix will be merged before Plasma 5.25.

M  +6    -1    sidebar/package/contents/ui/SubCategoryPage.qml

https://invent.kde.org/plasma/systemsettings/commit/b579a5d94a3afbd6f85a95cf368a29e8c96c2b92

A possibly relevant merge request was started @ https://invent.kde.org/plasma/systemsettings/-/merge_requests/132

*** Bug 453914 has been marked as a duplicate of this bug. ***

*** Bug 394800 has been marked as a duplicate of this bug. ***

*** Bug 421189 has been marked as a duplicate of this bug. ***

*** Bug 435873 has been marked as a duplicate of this bug. ***

*** Bug 458232 has been marked as a duplicate of this bug. ***

So the basic issue here is that Kirigami assumes that any icon with the `-symbolic` suffix is a monchrome icon, and it re-colors the icon to respect the color scheme. This isn't a safe assumption though. A variety of icon themes use colorful icons for this, and it's not against any spec because there is no spec to govern this. It's a *convention* from GNOME that icons whose names end with "-symbolic" are monochrome but it's simply not safe to assume.

We probably need to determine monochrome-ness by sampling the colors.

Git commit 66c6a75d44353c15101d872396be66b92d1c33e6 by Nate Graham, on behalf of Alexander Volkov.
Committed on 15/05/2023 at 12:49.
Pushed by ngraham into branch 'master'.

Fix painting of non-symbolic icons which are fallbacks for symbolic

A symbolic icon may be missing in an icon theme which may result in
loading the non-symbolic fallback. For example "window-close" may be
loaded instead of "window-close-symbolic". Then this fallback icon
should not be treated as symbolic.
FIXED-IN: 5.107

M  +14   -3    src/icon.cpp
M  +1    -0    src/icon.h

https://invent.kde.org/frameworks/kirigami/commit/66c6a75d44353c15101d872396be66b92d1c33e6

Git commit c6559f7142f71a80b5c92700fc7e51ca7bab697d by Nate Graham, on behalf of Alexander Volkov.
Committed on 15/05/2023 at 12:51.
Pushed by ngraham into branch 'kf5'.

Fix painting of non-symbolic icons which are fallbacks for symbolic

A symbolic icon may be missing in an icon theme which may result in
loading the non-symbolic fallback. For example "window-close" may be
loaded instead of "window-close-symbolic". Then this fallback icon
should not be treated as symbolic.
FIXED-IN: 5.107


(cherry picked from commit 66c6a75d44353c15101d872396be66b92d1c33e6)

M  +14   -3    src/icon.cpp
M  +1    -0    src/icon.h

https://invent.kde.org/frameworks/kirigami/commit/c6559f7142f71a80b5c92700fc7e51ca7bab697d

Git commit bdb322527fbc910ce7124a45dc43dfaa0fad1522 by Nate Graham.
Committed on 04/08/2023 at 16:58.
Pushed by ngraham into branch 'master'.

Icon: Remove automatic heuristic-based monochrome icon re-coloring

This feature has caused many bugs over the years and its value is
dubious to begin with. Automatically masking a colorful icon to instead
be monochrome based on this or that heuristic violates the integrity of
the user's icon theme and enforces a stylistic preference for monochrome
icons that is not appropriate to do at the library level.

If the user is using an icon theme whose icons have any color in them
despite being 16 or 22px size or using the `-symbolic` suffix, this
needs to be considered an intentional stylistic choice on the part of
the icon theme, and it isn't something that we should monkey with here.

As a bonus, we also reap an efficiency win by simply doing less
unnecessary work most of the time.

If a developer wants to do this masking anyway, they are still free to
set `mask: true` in their code and then it will happen on an opt-in
basis.
Related: bug 473001, bug 471803, bug 469978, bug 465422
FIXED-IN: 6.0

M  +2    -93   src/icon.cpp

https://invent.kde.org/frameworks/kirigami/-/commit/bdb322527fbc910ce7124a45dc43dfaa0fad1522