defaults.lua: fix canceled key bindings handling #14311
Conversation
In certain situations (including but not limited to begin window dragging), it is desired to cancel the current command completely. However, commands which have on_updown flag set require the command to be invoked in this situation. There is currently no way to know if the command is triggered normally or triggered because it is dropped. This adds a canceled state to mp_cmd which indicates this.
This allows libmpv clients to know whether the key binding is canceled and thus should normally be ignored.
|
Download the artifacts for this pull request: |
|
As far as I understand, events which the client/script now receives with a "canceled" flag were also received in the past - before this PR, just without the canceled flag, so the client couldn't distinguish canceled from normal keyup, right? I presume the value of It would probably help if the docs gave examples of how events get canceled, maybe one KB example and one mouse example (because they trigger on different down/up phase). Otherwise, IMO it's not necessarily obvious how to understand/interpret/use "the key is logically released but not physically released" explanation to "canceled". Currently This should also apply to js. |
|
Added the js change, and clarified the cancellation a bit with examples in the documentation.
Correct.
The scripts which don't use the
I think |
There is a subtle behavior difference for built-in/input.conf key bindings and key bindings registered by scripts: when a key binding is canceled (e.g. a mouse button is bound to a command, is pressed down, and then another key is pressed which is bound to another command), the command is not invoked if the binding is built-in/input.conf, but is invoked if it's registered by scripts, because it's handled with a different mechanism, which gives no way for scripts to detect this. Fix this by using the newly available canceled flag to detect this. If a key binding is canceled, the callback is now not invoked unless the key binding is registered with the complex option. In this situation, the callback is invoked with the canceled state available so that scripts can detect and handle this situation.
|
Thanks. |
There is a subtle behavior difference for built-in/input.conf key bindings and key bindings registered by scripts: when a key binding is canceled (e.g. a mouse button is bound to a command, is pressed down, and then another key is pressed which is bound to another command), the command is not invoked if the binding is built-in/input.conf, but is invoked if it's registered by scripts, because it's handled with a different mechanism, which gives no way for scripts to detect this.
Fix this by using the newly available canceled flag to detect this. If a key binding is canceled, the callback is now not invoked unless the key binding is registered with the complex option. In this situation, the callback is invoked with the canceled state available so that scripts can detect and handle this situation.