https://bugs.kde.org/show_bug.cgi?id=498530

Nicolas Fella <nicolas.fe...@gmx.de> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |nicolas.fe...@gmx.de

--- Comment #7 from Nicolas Fella <nicolas.fe...@gmx.de> ---
(In reply to Nate Graham from comment #5)
> As far as I can tell, the system tray is doing everything right: it's
> setting Kirigami.Icon's "active" property on hover, as evidenced by the fact
> that *some* of your 3rd-party tray icons are honoring it.
> 
> The only option I can see here is that for some of those icons,
> Kirigami.Icon's "active" state doesn't produce any visual changes for
> whatever reason. It looks like it's simply engaging the QIcon::Active mode
> in QIcon code itself, so it's possible this is also a Qt issue.
> 
> Regardless, moving to Kirigami for further investigation.

The difference seems to be between icons provided by name and icons provided as
a pixmap. For example Strawberry provides a pixmap and that doesn't get a
visible active effect.

When Kirigami.Icon gets a pixmap it loads that into an image
(https://invent.kde.org/frameworks/kirigami/-/blob/master/src/primitives/icon.cpp?ref_type=heads#L362)
and more or less directly renders that, without applying any mode.

I tried to change that by first creating a QIcon from the pixmap and then
obtaining a pixmap with the right mode from that. That ends up in
https://invent.kde.org/qt/qt/qtbase/-/blob/dev/src/widgets/styles/qcommonstyle.cpp#L6204
where some effects are applied, but for Active it doesn't apply anything. Given
how deep in Qt this is I'm rather hesistant about changing anything there

-- 
You are receiving this mail because:
You are watching all bug changes.

Reply via email to