Bug 433819

Summary: Mouse hover to change categories suffers from an irritating delay
Product: [Plasma] plasmashell Reporter: medin <med.medin.2014>
Component: Application Launcher (Kickoff) widgetAssignee: David Edmundson <kde>
Status: RESOLVED FIXED    
Severity: normal CC: aspotashev, bugseforuns, georgefb899, kde, mathieu, mikel5764, nate, null, plasma-bugs
Priority: NOR Keywords: usability
Version: 5.21.1   
Target Milestone: 1.0   
Platform: Other   
OS: Linux   
Latest Commit: Version Fixed In: 5.22
Sentry Crash Report:
Bug Depends on: 434904    
Bug Blocks:    
Attachments: Slow mouse hover
vivaldi submenu delay

Description medin 2021-03-01 21:42:53 UTC
When mouse pointer is passing over a category the timeout to show the related applications is really long and makes the selection slow.

Operating System: Manjaro Linux
KDE Plasma Version: 5.21.1
KDE Frameworks Version: 5.79.0
Qt Version: 5.15.2
Kernel Version: 5.4.100-1-MANJARO
OS Type: 64-bit
Comment 1 Nate Graham 2021-03-02 19:30:35 UTC
Cannot reproduce. Can you attach a screen recording so I can see what you see? Thanks!
Comment 2 medin 2021-03-02 22:28:05 UTC
It's like the new launcher need half second or more to capture mouse event to show apps of that category. See attached video for more info.
Comment 3 medin 2021-03-02 22:28:38 UTC
Created attachment 136330 [details]
Slow mouse hover
Comment 4 Nate Graham 2021-03-03 00:50:23 UTC
Yes, this is intentional.

However it's clearly not ideal. We're working around the fact that we don't have a triangle menu filter, which would eliminate the need for a hover delay in the first place.

Alternatively we could move the sidebar over to the opposite side so that you never need to pass your cursor over it to reach the main view (SimpleMenu does this).
Comment 5 mateMat 2021-03-09 22:55:57 UTC
Actually, it is a very difficult choice and tuning to make, i think the delay should only enable the favorites to be selected quickly, but without impacting the fast category selection.

Very hard to set properly because the favorites are located at the top of the list of categories.

Maybe moving the favorites as a row of app icons at the bottom of the UI might do the trick. Functional, but it might be ugly.
Comment 6 medin 2021-03-09 23:51:45 UTC
The problem is that each user has its own way to access launcher, some left click by mouse on launcher icon and some trigger it by meta key, so putting Applications sidebar on right or left or as row will never solve the problem. What can be done is to give user more options to customize how launcher looks to fit personal usage.

Some points that can free devs from the struggle of giving unified solution is to offer extra features to adapt launcher UI and behavior :

- Option to change how app selection is done : by mouse hover (timeout) or by mouse left click.

- Option to change mouse hover timeout, this way user can adapt the timeout to mouse speed.

- Option to move Applications/Places sidebar to left or right side of the launcher.
Comment 7 george fb 2021-03-19 11:54:55 UTC
Created attachment 136842 [details]
vivaldi submenu delay

What about delaying only the loading of the applications?
And highlighting the categories happens instantly.

Vivaldi does that for sub-menus in its context menu, can be seen in the attachment.
Comment 8 David Edmundson 2021-04-11 06:22:55 UTC
*** Bug 435600 has been marked as a duplicate of this bug. ***
Comment 9 Nate Graham 2021-04-28 14:35:55 UTC
Fixed by David Edmundson in Plasma 5.22 by implementing a Triangle menu filter for the categories list with https://invent.kde.org/plasma/plasma-workspace/-/commit/36ca390f56115ae9cbb1423cd00976e8dffec4d9 and removing the hover delay in https://invent.kde.org/plasma/plasma-desktop/-/commit/d3c1366ff57775c4ee5a6dc9e105da118a0d74a0!
Comment 10 Patrick Silva 2021-06-01 11:23:03 UTC
This issue persists on Plasma 5.22 beta, Arch Linux.
sometimes kickoff takes ~2 seconds to highlight a category on mouseover and
lists its apps.
Comment 11 Nate Graham 2021-06-01 17:14:29 UTC
The timeout that we removed was never 2 seconds long; if you're seeing a 2 second delay, that sounds like a separate issue unrelated to this bugfix. Can you please file a new bug report for it?