[RFC] Global binding

[Quentin Glidic]

On 30/12/2013 22:51, Bill Spitzak wrote:
> Quentin Glidic wrote:
>> Here is the simple way I think we could solve this problem: a
>> wl_seat.bind(action) request.
>>
>> The first important point is here: the client only binds an
>> *action*. The action is a describing string and does not leak the
>> key which is bound. There would be a set of standard actions, some
>> vendors ones, and user custom ones (which application would have to
>> support too with a custom setting).
>
> I don't understand the reasoning behind this. Users want to say
> "this button does this action" in the program that is going to
> perform the action, if there is any choice. I am a little stumped as
> to what security or usability problem you are trying to solve.

I use a mouse button as my Push-to-Talk button. This button is
detected as “History back” by my web browser, and *I want to have both
working.*
I other words, I do not want the action (Push-to-Talk) to eat the
button! And I think this is a requirement because this is how things are
working on X or Windows currently. Since that would allow to spy the
input, we need the compositor to abstract the key/button information.

Also, binding gestures and complex stuff is a really good feature to
have (think of three-thingers scrolling to up/down volume as an
example), and more easily done on the compositor side since that would
require to expose yet another information (pointer movement, touchscreen
touches) to the client.


> Events should certainly be decoded to more like the xkeysym level by
> the compositor, so you can get the "volume up key" without having to
> figure out which scan code is that key. But that decoding should not
> be specific to this binding api.

AFAIU, the decoding is done by libxkbcommon and it was designed so that
clients would have to support that explicitly. This has nothing to do
with global bindings.

Please note that music and video players are not currently using
multimedia keys directly: mplayer and VLC are using the space bar as
play/pause (while focused, of course), VLC uses the mouse wheel to
control volume. This is a good design, to keep the global keys usable at
the system level (e.g. controlling the PCM volume).


>> The third point: which application to send the events to
 >> The fourth (optional?) point: the compositor can have complex
>> heuristics to prefer one client to another.
>
> Just allow the client to say "I did not use the action" and the
> compostor can send it to the next client.

That would require a round trip and that would be wrong is some (many?)
cases: I have two music players A and B, I focused B last, why would A
have to decline the action if it can handle that perfectly, since it
does not have the knowledge that B exists at all?


> Probably should not send it as a "normal" event every however:

As I said, in all the current cases, this is the case: the event *is*
both and action and a normal one. And I do want to keep that really
useful feature that every user (player in the TS case) will expect.


>> Last but not least: what about input statistics applications?
>
> They are probably interested in everything that happens and will
> need a different api? […]

Sure they will need a different interface, I am pretty sure the last
part of my email was about that. :-)

-- 

Quentin “Sardem FF7” Glidic