Menu hover behavior

[po5]

I find the behavior introduced in 5790169 confusing, ran into it and this is something I'd report as a bug if I didn't know it was intended behavior.
If I read through #964 correctly this was trying to solve the action deactivating when using keyboard navigation and slightly bumping into your mouse on accident.
This behavior should only kick in when an action is selected (should NOT apply to the whole menu item as the menu selection index doesn't get reset even when moving the mouse, making the workaround useless there), and only if it was selected by keyboard navigation.
I also think we could allow any cursor movement as long as it's outside of the menu. This may have been the behavior at some point already?

Noticed it when I tried to gauge why hovering through different items' actions feels so flickery, there are two issues:

• The white accent on the hovered menu item goes away when hovering on an action. I understand why you've done that, it makes keyboard navigation more clear.
• The flickering footnote steals more of your vision's focus than necessary.

A solution that addresses both of these issues would be extending the action's hover area to span the menu item's entire height, and a bit of leeway to the sides as well.
I don't think anyone is purposefully trying to click within the small gaps I highlighted in red:

There is a conflict between cursor and keyboard navigation when hovering on an action button. Pressing tab does what it should, but it very quickly gets reset back to obey the cursor. The keyboard should be able to take over until there is a new mouse movement.
While the same issue is not exhibited when using the keyboard to move up/down through menu items in a small enough playlist that it doesn't trigger scrolling, it should navigate to the new menu item as a whole instead of its action if the action's hover state was caused by the cursor and not the keyboard. Hope I explained this well enough, below is a screenshot of a confusing state this causes when switching from mouse to keyboard nav.

[dyphire]

Putting prompts for actions into footnote does save menu space, but it becomes less intuitive when there are a lot of items in the menu. A new compromise may need to be found.

[tomasklaen]

@po5 do the commits above solve your issues?

Putting prompts for actions into footnote does save menu space, but it becomes less intuitive when there are a lot of items in the menu. A new compromise may need to be found.

I'm all ears, I can't think of any. And I personally don't think this is an issue at all. It's quick and easy to learn that these show up there, so you know they are there when you need them.

[dyphire]

I'm all ears, I can't think of any. And I personally don't think this is an issue at all. It's quick and easy to learn that these show up there, so you know they are there when you need them.

Personally, I might favor the previous solution, but that doesn't mean it's really better. At least for the operations that already exist within uosc most of the buttons' icons are clear enough about the functionality that it's acceptable to leave it as it is.

Edit: The footnote for a button that actually only needs to be viewed once to understand its function is an acceptable inconvenience in relation to the benefits it brings.

[po5]

do the commits above solve your issues?

It's still possible to hover the vertical gap

So flicker still happens. Horizontal gap seems accounted for though.

uosc974.mp4

Mouse preventing keyboard navigation is fixed. And I guess the keyboard navigation handoff when previously hovering an action isn't that bad so don't bother with the last line of the original issue.

[tomasklaen]

^ That should fix it. Hopefully I didn't break anything.