Bug 455724 - Kickoff should have 2 separate cursor items for mouse and keyboard navigation
Summary: Kickoff should have 2 separate cursor items for mouse and keyboard navigation
Status: RESOLVED DUPLICATE of bug 455674
Alias: None
Product: plasmashell
Classification: Plasma
Component: Application Launcher (Kickoff) (show other bugs)
Version: 5.25.0
Platform: Other Linux
: NOR normal
Target Milestone: 1.0
Assignee: Plasma Bugs List
Depends on:
Reported: 2022-06-21 14:33 UTC by Komorebi
Modified: 2022-06-22 23:37 UTC (History)
3 users (show)

See Also:
Latest Commit:
Version Fixed In:

How it looks in Gnome (175.81 KB, image/png)
2022-06-21 21:30 UTC, Komorebi
How it looks in dolphin (204.25 KB, image/png)
2022-06-22 22:24 UTC, Komorebi

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