Bug 489761

Summary:	Kirigami.Icon lightening effect instantly resets, rather than smoothly resetting
Product:	[Frameworks and Libraries] frameworks-kirigami	Reporter:	tempqd <variable_valuables761>
Component:	general	Assignee:	kdelibs bugs <kdelibs-bugs-null>
Status:	RESOLVED FIXED
Severity:	minor	CC:	materka, nate, notmart
Priority:	NOR
Version First Reported In:	Master
Target Milestone:	Not decided
Platform:	Other
OS:	Linux
Latest Commit:		Version Fixed In:	6.8
Sentry Crash Report:
Attachments:	Full hover animations; interrupted hover; interrupted un-hover

Description tempqd 2024-07-05 01:05:35 UTC

Created attachment 171389 [details]
Full hover animations; interrupted hover; interrupted un-hover

SUMMARY
The hover highlight animation is a smooth fade/blend. However, if you unhover before the animation has completed, it instantly resets back to the initial state.

Hard to notice at normal animation speeds; it just looks like something is slightly off or glitchy. But at slow animation speeds it is very apparent.

Video attached that shows:
1. Full hover and unhover animations, smoothly highlighted
2. Hover animation interrupted, instantly un-highlighted
3. Un-hover animation interrupted, instantly re-highlighted

Expected:
1. Full hover and unhover animations, smoothly highlighted
2. Hover animation interrupted, smoothly un-highlights over time
3. Un-hover animation interrupted, smoothly re-highlights over time

(Note this is only visible with Breeze light due to bug#489756)


OS: openSUSE Krypton (today's git master)

Comment 1 Nate Graham 2024-07-27 23:07:06 UTC

I cannot reproduce this on git master and strongly suspect it was fixed by removing the Morphing Popups effect.

Comment 2 Nate Graham 2024-07-27 23:08:02 UTC

Oh, but if you're on master, you also don't have the Morphing Popups effect. Hmm.

Comment 3 tempqd 2024-07-28 01:49:24 UTC

Oh sorry, in retrospect I was completely ambiguous about this: this bug report refers to the *color of the tray icon itself changing* (getting lighter), not the popup boxes. Oops!

My eyes completely glossed over the tooltip animations in my screencast. I will have to more closely investigate those as well separately, and I also want to make sure they visually mesh well with the icon animations after they're fixed.

If this makes sense, I'll let you change the title again?

Comment 4 tempqd 2024-09-22 20:57:14 UTC

Title changed. (Not sure if this bug is specific to the system tray's usage of Kirigami.Icon, but I moved it to the latter category to be consistent with my other related bugs in Kirigami.Icon)

Comment 5 tempqd 2024-10-03 01:59:41 UTC

I think this might be due to improperly ordering the paint nodes in the Qt Quick scene graph in this function https://invent.kde.org/frameworks/kirigami/-/blob/03efe7da6ee92a4fbf47f4c602ffdc2200298d49/src/primitives/icon.cpp#L206 ?

Unless it's instead lurking in systemtray's hover handling somehow? (But that code is more confusing unfortunately)

Sorry I can't test myself in the near future, but in case anyone's interested in taking a look.

Comment 6 tempqd 2024-10-26 18:43:29 UTC

After https://invent.kde.org/frameworks/kirigami/-/merge_requests/1645 effectively disables this highlight animation in system tray, this is no longer visible there. But if the animation gets re-enabled, this may pop up again.

And I think it's still an issue with Kirigami.Icon itself with animations enabled, but not sure where to test that in Plasma.