[PATCH weston] input: don't send to clients key events eaten by bindings

[Bill Spitzak]

On 11/21/2014 10:30 AM, Daniel Stone wrote:

> As in the first quoted section, I think it's not really reasonable to
> guard against the possibility of Mod+S taking a screenshot in the
> compositor, but the client having a shortcut for Mod+S+X. So I think we
> can take the easy way out of saying:
>    - for any hotkeys which are _solely_ combinations of modifiers and
> _not_ non-modifier keys (e.g. Exposay as it is today), then we only take
> action on release
>    - for all other hotkeys (i.e. including non-modifier keys), then we
> take action on press
>    - if a client has a hotkey combination which conflicts with the above
> (e.g. the Mod+S vs. Mod+S+X case), then that's their problem, because
> it's a stupid hotkey combination anyway

That seems correct to me. The point is that this sort of action is 
irregardless of whether it is a "server shortcut" or not. If a client 
had Ctrl+Shift do something and Ctrl+Shift+X do something else, then it 
will trigger the first action on the release of Shift. The second action 
it would trigger on the press of 'X'. The logic in the compositor is 
identical. Nothing special is done about a key up or down until it 
figures out it triggered a shortcut, then that up or down event is not 
sent to the client.

I suppose in theory a client could have Ctrl+X and Ctrl+X+Y as shortcuts 
and it then treats Ctrl+X as a modifier. And this seems to have led to 
the concern that the server has to be able to do this, without the 
ability to query other programs whether there is a conflicting key 
combination. However I don't think there are any clients that do this, 
for the simple reason that it will make the Ctrl+X shortcut look broken 
or slow and contrary to user expectations. Since clients with a full 
ability to implement this do not do this, there is no reason to try to 
do it in this case where it is actually not possible.