Bug 455724

Summary: Kickoff should have 2 separate cursor items for mouse and keyboard navigation
Product: [Plasma] plasmashell Reporter: Komorebi <markovs.i.mail>
Component: Application Launcher (Kickoff)Assignee: Plasma Bugs List <plasma-bugs>
Status: RESOLVED DUPLICATE    
Severity: normal CC: mikel5764, nate, noahadvs
Priority: NOR    
Version: 5.25.0   
Target Milestone: 1.0   
Platform: Other   
OS: Linux   
Latest Commit: Version Fixed In:
Attachments: How it looks in Gnome
How it looks in dolphin

Description Komorebi 2022-06-21 14:33:40 UTC 
From the UX perspective, navigation with keyboard and mouse are 2 different type of things. Sharing the same cursor item between 2 different types of input makes bugs like https://bugs.kde.org/show_bug.cgi?id=455674 possible. But even if it get fixed, there's still a situation when user hits meta, performs a search and hits enter to run the first entry without paying attention to mouse cursor and item selected. But if mouse cursor is placed in menu area and hovers another search result, the enter buttons opens it instead of the first entry. 

What I'm trying to say is there's no situation in real life when it's helpful to hover search result with the mouse, but select it with enter, so hovering search result with a mouse should never select it.
Comment 1 Noah Davis 2022-06-21 15:41:05 UTC 
I agree that there's an annoying situation where the mouse's position can cause the focus to move away from the top item when searching. With that said, the intention isn't to make it so you can hover and then press enter, it's to make it so that switching to arrow keys moves the highlight you already see instead of starting from a completely different location.

I think what's happening with the search view is the animation making the search results move downwards causes an item to register a hover change. We should probably block allowing hover to change the focus until the animation is complete. This way the first item is always focused when starting or changing a search.
Comment 2 Nate Graham 2022-06-21 18:31:42 UTC 
I think we should just fix Bug 455674; having two selection sources would be super weird and nonstandard IMO.

*** This bug has been marked as a duplicate of bug 455674 ***
Comment 3 Komorebi 2022-06-21 21:29:22 UTC 
Maybe I wasn't correct enough with my explanation.  KDE is actually the only DE that acts this way. most of DEs and operating systems just highlight item on hover and keep keyboard cursor completely separated from mouse actions. There's no 2 different cursors, there's acrually only a keyboard one and cursor hover animation. See the Gnome screenshot attached.  This it pretty standard behavior and gold standard from UX perspective.   
In Windows it works the same way, but I can't demonstrate it, Gnome boxes don't run windows 11 unfortunately.
Comment 4 Komorebi 2022-06-21 21:30:04 UTC 
Created attachment 150028 [details]
How it looks in Gnome
Comment 5 Nate Graham 2022-06-22 15:51:05 UTC 
Yeah, that's two different highlight effects. If I press the return or enter key, which thing gets activated? I don't think that's a good idea at all.
Comment 6 Komorebi 2022-06-22 22:23:54 UTC 
Again, that's not an idea, it's a pretty standard UX thing. When you tab with keyboard over the elements, you know which one is going to be activated with enter. 
All apps are actually work the same way, see dolphin screenshot.
Comment 7 Komorebi 2022-06-22 22:24:30 UTC 
Created attachment 150074 [details]
How it looks in dolphin
Comment 8 Noah Davis 2022-06-22 23:37:44 UTC 
In Kickoff, focus control behaves like menu focus control.