Bug 473001

Summary:	Accessing icon using the -symbolic suffix removes all color, even intentional color
Product:	[Frameworks and Libraries] frameworks-kirigami	Reporter:	Nate Graham <nate>
Component:	general	Assignee:	kdelibs bugs <kdelibs-bugs>
Status:	RESOLVED FIXED
Severity:	normal	CC:	notmart
Priority:	NOR
Version:	Master
Target Milestone:	Not decided
Platform:	Other
OS:	Linux
Latest Commit:	https://invent.kde.org/frameworks/kirigami/-/commit/bdb322527fbc910ce7124a45dc43dfaa0fad1522	Version Fixed In:	6.0
Attachments:	Mis-colored symbolic icons

Description Nate Graham 2023-08-04 14:37:08 UTC

Created attachment 160738 [details]
Mis-colored symbolic icons

See attached screenshot from Cuttlefish, which uses Kirigami.Icon to draw these icons. You can see how `delete-comment` is mostly black with a small red X, while `delete-comment-symbolic` colors the red X to be black.

If the app explicitly asked for `icon-name-symbolic` and that icon exists, we should use it without any re-coloring, on the assumption that an icon explicitly suffixed with `-symbolic` that includes some color anyway knows what it's doing.

And if `icon-name-symbolic` is not found and it has to fall back to `icon-name`, we should still not do any re-coloring, because in this case, `icon-name` may be colorful, and if the user is using an icon theme that intentionally uses colorful icons for buttons and toolbars and such they expect to see colorful icons there.

As such, I propose removing the entire re-coloring infrastructure. This will also fix the following bugs:
- Bug 471803
- Bug 469978

Comment 1 Bug Janitor Service 2023-08-04 14:57:25 UTC

A possibly relevant merge request was started @ https://invent.kde.org/frameworks/kirigami/-/merge_requests/1192

Comment 2 Nate Graham 2023-08-05 15:47:51 UTC

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 471803, bug 469978, bug 465422, bug 451538
FIXED-IN: 6.0

M  +2    -93   src/icon.cpp

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