Bug 435873 - Kirigami.Icon is autocolored even though it should not be
Summary: Kirigami.Icon is autocolored even though it should not be
Status: RESOLVED DUPLICATE of bug 451538
Alias: None
Product: frameworks-kirigami
Classification: Frameworks and Libraries
Component: general (show other bugs)
Version: 5.81.0
Platform: Other Linux
: NOR normal
Target Milestone: Not decided
Assignee: Marco Martin
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2021-04-18 11:54 UTC by Michail Vourlakos
Modified: 2022-08-25 13:20 UTC (History)
1 user (show)

See Also:
Latest Commit:
Version Fixed In:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Michail Vourlakos 2021-04-18 11:54:22 UTC
SUMMARY
Latte Git version is using Kirigami.Icons these days. I opened Latte git version under Gnome 40. The problem is that some icons are forced painted even though they should not. The issue is reproduced only under Gnome40 and not Plasma because Plasma.LibTaskmanager provides something different Kirigami.Icon.source .

By checking https://github.com/KDE/kirigami/blob/master/src/icon.cpp#L309 I think lines #309-320 is the issue. In these lines if guessMonochrome() function provides faulty results then Kirigami.Icon is forced to be painted ALWAYS. To check the scenario I provided isMask:false and color:"red" and the icon was painted RED even though it should not.


An icon that guessMonochrome() fails is from Materia Icon Theme the kwrite/kate icons.


STEPS TO REPRODUCE
1. Use Materia Icon theme
2. Open Latte Git version under Gnome 40
3. Open KWrite

OBSERVED RESULT
KWrite icon is monochromatic painted even though it should not

EXPECTED RESULT
KWrite icon should not be monochromatic painted

SOFTWARE/OS VERSIONS
Linux/Gnome: Gnome 40
(available in About System)
KDE Plasma Version: 5.15.4 
KDE Frameworks Version: 5.81.0
Qt Version: 5.15.2
Comment 1 Nate Graham 2021-04-21 20:36:49 UTC
Can confirm; I was looking at this code recently myself, and noticed that it seemed a bit suspect.

Would you be interested in submitting a merge request to fix it? Might be as simple as always disabling the auto-coloration behavior when isMask is false.
Comment 2 Michail Vourlakos 2021-04-21 21:11:24 UTC
(In reply to Nate Graham from comment #1)
> Can confirm; I was looking at this code recently myself, and noticed that it
> seemed a bit suspect.
> 
> Would you be interested in submitting a merge request to fix it? Might be as
> simple as always disabling the auto-coloration behavior when isMask is false.

I think it is better to be fixed by the one that introduced guessMonochrome() function. It is pretty clear that its creator wants a code path that will apply autocoloring automatically and it is not pretty clear how it should be disabled. 

My thought is that this codepath was introduced for PlasmaMobile top panel that is probably autocolored so it should be better to be fix by them because anything else will probably break their current plasma mobile implementation.
Comment 3 Nate Graham 2022-08-25 13:20:38 UTC

*** This bug has been marked as a duplicate of bug 451538 ***