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.
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.
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. Probably should not send it as a "normal" event every however:
Last but not least: what about input statistics applications?
They are probably interested in everything that happens and will need a different api? This is why ignored actions never turn into normal events.
_______________________________________________ wayland-devel mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/wayland-devel
