Bug 489761 - Kirigami.Icon lightening effect instantly resets, rather than smoothly resetting
Summary: Kirigami.Icon lightening effect instantly resets, rather than smoothly resetting
Status: RESOLVED FIXED
Alias: None
Product: frameworks-kirigami
Classification: Frameworks and Libraries
Component: general (show other bugs)
Version: Master
Platform: Other Linux
: NOR minor
Target Milestone: Not decided
Assignee: kdelibs bugs
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2024-07-05 01:05 UTC by tqd8
Modified: 2024-10-28 15:27 UTC (History)
3 users (show)

See Also:
Latest Commit:
Version Fixed In: 6.8
Sentry Crash Report:


Attachments
Full hover animations; interrupted hover; interrupted un-hover (968.12 KB, video/mp4)
2024-07-05 01:05 UTC, tqd8
Details

Note You need to log in before you can comment on or make changes to this bug.
Description tqd8 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 tqd8 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 tqd8 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 tqd8 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 tqd8 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.