SUMMARY Upon trying Plasma 6.0.2 (and KF6), I noticed that the delay when opening menus on Qt-based software in KDE - that most of us perceive as lag - can be traced down to the menus waiting for the button-click animation to end before opening. Of course, this hinders the feeling of responsiveness of the whole desktop environment; is it a known behavior? I could not find anything related to this, maybe I used the wrong keywords. STEPS TO REPRODUCE 1. Open a Qt-based application which presents a "slow" animation for button-clicks, like systemsettings or Discover; 2. Click the Hamburger menu 3. Notice the delay between the click and the menu showing up OBSERVED RESULT The menu opens when the button-click animation ends. EXPECTED RESULT The menu opens upon click, and the animation speed is tuned by the user. SOFTWARE/OS VERSIONS Linux/KDE Plasma: openSUSE Tumbleweed (available in About System) KDE Plasma Version: 6.0.2 KDE Frameworks Version: 6.0.0 Qt Version: 6.6.2 ADDITIONAL INFORMATION I think this is an old issue, but I only noticed the cause today. My suggestion is rather noobish: I suppose we have a sequential .onClick -> doAnimation -> openMenu setup in the code, if possible, making the two instruction parallel could solve the problem.
I'm not able to reproduce this issue. If I turn the global animation speed down to a very low value and click on a hamburger menu in any app, the menu popup begins to appear immediately. Now, its appearance animation does become very slow. But it starts immediately. Are you perhaps saying that you don't think there should be an appearance animation at all, and instead menus should appear immediately, and only animate their *dis*appearance?
Created attachment 167959 [details] A short screencast showing the unexpected behavior
Thank you for testing it out! Actually, I think that the issue is most visible when you set the animation speed to instantaneous. I attached a screen recording of the hamburger menu behavior in systemsettings. It is a slight delay (and maybe you'll think that I am crazy), but I hope to make my point crystal clear with this. Wish you a great weekend, folks! :) PS the interface is in Italian. The slider is the "animation speed" one.
I think you're noticing that the menu appears on mouse release, not on press. This is done on purpose so that you can "change your mind" and release elsewhere to avoid opening the menu. In your screencast, I think you're clicking with various levels of speed, and observing that the menu opens slowly when you do a click-and-briefly-press-and-release. But when you do a "click-and-immediately-release", the menu opens faster. This would be by design.
Sorry folks, I had the opportunity to come back at this only today. Nate, while investigating your suggestion I noticed an inconsistency between two groups of apps: dolphin/kate and systemsettings/discover/systemmonitor. The former group shows the hamburger menu immediately after a click, while the latter introduces a delay, maybe due to an additional animation for the button. I have attached a new screencast.
Created attachment 168508 [details] A comparison between the button animation across dolphin/kate/systemsettings/systemmonitor As you can see there is visual inconsistency among the animations. What happens immediately for dolphin/kate, takes a fraction of a second for systemsettings/systemmonitor(/discover)
Aha, it's the fact that in QML apps, buttons that open menus open on release and not on press, which unfortunately is a Qt issue. See Bug 439734. *** This bug has been marked as a duplicate of bug 439734 ***