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

[Giulio Camuffo]

Oh, i didn't realize we dropped the ML. adding again.

2014-10-10 21:17 GMT+03:00 Bill Spitzak <spitzak at gmail.com>:
> On 10/09/2014 11:42 PM, giuliocamuffo at gmail.com wrote:
>
>>> Are you proposing something else?
>>
>>
>> IsSpaceKeyDown() should always return false.
>> What I'm looking for here is consistent behaviour. What happens in your
>> example if the user releases and presses space again? The compositor will
>> switch to another window, and the client will not do anymore what it is
>> supposed to do with space. That's broken behavior, and the user will wonder
>> why sometimes space works and some other time it has another effect
>> entirely.
>
>
> I still think we are just not agreeing on terms because I am quite confused
> as to what you are saying.
>
> The client will not get an keypress event for the space. Therefore if they
> have some action for the space key itself they will not do it. If typing
> space is used by the compositor to switch focus then the client will *never*
> see a keypress for space because the compositor will not deliver a keypress
> event for space to any client. It is consistent in that space *never* works.
>
> However imagine the client has a "hold down space and type 'x'" action. This
> *should* work. This is because when the user types 'x' the client gets a
> keypress event for 'x', and then uses the IsSpaceKeyDown() to determine that
> space is held down, that returns true, and does this action.

Ok, so let's change the example. Space doesn't switch the active
window, but toggles the speaker mute. So hitting space will not send a
key event to the client, which will not know space is pressed, so your
nice space+x shortcut won't work.
If the user presses space and switches to another window before
releasing it, the shortcut will suddenly and inexplicably work, but
the user will be able to only use it when coming from another window.
Hardly a reliable feature, I would just call it broken and I don't
think we should implement broken behavior. The fact that X does so is
irrelevant.

>
> I'm quite certain this is exactly what users expect. For an actual
> real-world example if you type Alt+Tab in some window managers the app that
> gets the focus acts like Alt is held down. I know you said this already
> works for modifier keys, but I then don't understand why you don't want this
> to work for other keys.