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
A possibly relevant merge request was started @ https://invent.kde.org/frameworks/kirigami/-/merge_requests/1192
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