Adding directional keyboard support to OSC

[iainsaxonhome]

It looks like issues are disabled for this repository so in the meantime I figured I'd draft a PR as a preview for what I'm working on and will clean up the PR as I go ;) .

I want MPV to work using simple directional keyboard input for a HTPC just as Kodi or Jellyfin Media Player do but I couldn't find an existing solution for this.

I'm very new to LUA so the code at this stage is very rough to get it working :) .

When the interface is showing the up, down, left, right, enter and esc keys are bound to new keyboard controls to navigate the OSC elements that appear on the screen. Like the Jellyfin Media Player the interface is navigated up and down in rows and then left and right between the row's controls with no looping. If a directional key is used it sets the OSC to always display until esc is pressed to return it to auto. Pressing enter will trigger either the element's bound enter event handler or the mbtn_left_up.

To do:

• left and right while the seek bar is active should skip back and forth
• activating these keyboard bindings should be managed via the user_opts
• make the highlighted style nicer
• clean up code

I'm hoping to get these items sorted soon.

Please let me know if you have any thoughts or suggestions for this :) .

Thanks!

[cyl0]

Looks good, should be a good addition so long as it can be toggled via the user_opts.

[iainsaxonhome]

I've adjusted the code to include an option keyboardnavigation (it looks like all lower-case, no spaces is the standard naming here), left and right keys while the seek bar is highlighted will seek 5 seconds in the respective direction and I've tried tweaking the highlighted button style.

I wasn't able to override the button colour properly so its currently blue like used elsewhere in the script. The blue works well enough but its not immediately noticeable when the seek bar is highlighted because its a small change in colour where I would have preferred to use something different like an orange that works on light and dark backgrounds.

[iainsaxonhome]

@cyl0 release 0.4.0 is now merged back into this feature branch and I have made the keyboard controls a little more dynamic. This is so it can react to whether the window controls are enabled (this appears to be tied to the current state so can't be predetermined as window_controls_enabled() returned false on initialisation) and whether the new jump buttons are shown.

I'm not sure if there is a more dynamic way to generate this keyboard mapping or if it should remain fixed as it is now and when new buttons are added the name is simply added to the row they belong on. I don't think being dynamically generated is a major issue as it only affects what is in this script.

Do you think this feature is OK as it is now?

[cyl0]

Hi there, sorry for the late response. I think that it seems good to go, except for the title which seems to be highlighted even when the keyboard navigation is disabled. Other than that, it looks great!

[iainsaxonhome]

All good :) . I'll check out the issue with the highlighted title as soon as I can. I suspect it might happen if the mouse has hovered over it and made it active where the title should be ignored as there is no action for it.

Currently with the OSC there is no feedback to tell the user that the button is being hovered by the mouse. Do you think hovering over a button with the mouse should show the highlighted state to convey its ready to be clicked whether keyboard navigation is active or not?

PS didn't mean to close the PR and re-open, accidental mouse click :) .

[cyl0]

I think that it would be better off without a highlight on hover since your cursor would be there anyway, but it could be a nice option to have for those who want it.

[iainsaxonhome]

@cyl0, I ended up removing the code responsible for highlighting buttons as it wasn't working 100% on mouse over/off interactions and the mouse off bit was conflicting with the keyboard highlighted element ;) .

[cyl0]

Now the cy_audio button is highlighted blue even if the keyboard controls are turned off, was this behaviour intended?

[iainsaxonhome]

@cyl0, good catch, sorry missed that one :) . Updated PR ;) .

[cyl0]

Looks good to me, I'll go ahead and merge it.

[dexeonify]

Just a heads-up, this PR reverted commits from my PR. See 5dfda84.
Should have done a rebase :P

[cyl0]

Whoops, rookie mistake. I've re-merged it in a new PR. Thanks for pointing it out.