Introducing osc keyboard control.

[kz6wk9]

Giving control of some keyboard keys to the osc makes possible for us
to show the changes being made without resorting always to the osd,
which makes the player appearance somewhat weird, for example, when
seeking, the only available behavior was either disabling
osd-on-seek and having absolutely no visual feedback of the seeking or
accepting the other indicator(osd) that would appear on top of the
osc(which clearly makes no sense).
The only thing bad I could think about with this new default behavior
is if the user does not want the osc to mess with the keyboard (eg.
because he already has some script that changes those same keys), for
this case theres a new option that can be called with
--script-opts=osc-controlkbd=no which makes the osc not ever touch any
keyboard key, thus bringing back the old behaviour.

[kz6wk9]

Closes #7891, #3826(probably).

[avih]

Thanks.

Do I understand correctly that basically your goal is to pop up the OSC on seek instead of the OSD?

[avih]

Do I understand correctly that basically your goal is to pop up the OSC on seek instead of the OSD?

After some discussion on IRC it was agreed that this was the goal.

However, the choice to use key bindings is a compromise compared to finding another trigger to show the osc (for instance, registering the seek event):

• It hardcodes the keys, which is not fun for the user which already have their own key bindings for seeking.
• It hardcodes the seek durations. Again - the user may have their own preference for durations.

Additionally, this PR changes defaults.lua without any explanation. I don't know whether this is required for correct operation, or only a temporary test which left at the PR accidentally, but either way, changes to defaults.lua should be in separate PR, and with very good reasons.

[kz6wk9]

As we discussed, these changes will probably be better implemented later in a different manner after the OSC code gets some changing. So I'm closing this, thanks !