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

[Giulio Camuffo]

2014-11-19 13:42 GMT+02:00 Pekka Paalanen <ppaalanen at gmail.com>:
> On Tue, 18 Nov 2014 18:54:04 +0200
> Giulio Camuffo <giuliocamuffo at gmail.com> wrote:
>
>> 2014-11-13 13:30 GMT+02:00 Daniel Stone <daniel at fooishbar.org>:
>> > Hi,
>> >
>> > On Thursday, November 13, 2014, Giulio Camuffo <giuliocamuffo at gmail.com>
>> > wrote:
>> >>
>> >> 2014-11-13 12:06 GMT+02:00 Daniel Stone <daniel at fooishbar.org>:
>> >> > But this is just a client issue, and nothing in sending the full keys
>> >> > array
>> >> > precludes this working.
>> >> >
>> >> > If Alt+X is a modifier (i.e. any time Alt+X is held, pressing Y triggers
>> >> > the
>> >> > shortcut), then the client can use the keys array to notice this, and
>> >> > ensure
>> >> > the shortcut is fired.
>> >> >
>> >> > If Alt+(X+Y) is a cumulative shortcut, then the client knows from seeing
>> >> > X
>> >> > in the enter array but not a key event, that it must wait for a release
>> >> > on X
>> >> > before it arms the shortcut for Y.
>> >>
>> >> But no, because, when the focus isn't switched, there is no enter
>> >> event and no keys array. The client has no idea X was pressed, so it
>> >> can't possibly trigger the binding.
>> >> So without the patch this is not consistent. Depending on whether the
>> >> compositor binding switches the focus, the client binding works or it
>> >> doesn't work.
>> >
>> >
>> > A problem we can solve by switching the focus. ;) I agree that it's annoying
>> > to always do this for every hotkey, so we could introduce a new
>> > wl_keyboard::leave_temporary which would inform the client that it's about
>> > to get another enter event very shortly, but shouldn't redraw itself
>> > insensitive or anything.
>> >
>> > Alternately, we could bump the wl_keyboard version to just allow for
>> > consecutive enter events and never send a leave in these temporal cases.
>>
>> Do we really need to bump the version? The description of
>> wl_keyboard.leave says " Notification that this seat's keyboard focus
>> is on a certain surface.", it doesn't say the leave and enter events
>> always go in pair, so it seems to me we can just send the new enters
>> without changing anything.
>
> We have lots of things we simply imply instead of having it written
> down. But I also think we don't even need to consider this.
>
> I don't see problem having the compositor itself steal the keyboard
> focus when a hotkey goes down. It would cause a wl_keyboard.leave to
> the client, and the keyboard focus would stay in the compositor as long
> as the grab is active (hotkeys always install a grab to prevent key
> events going to clients). When the grab ends, keyboard focus
> can return, and we naturally get the wl_keyboard.enter with the list of
> keys. I think this even allows both the compositor first handling the
> hotkey-down, and then the app seeing the key already-down.
>
> We even have one hotkey that won't release the grab on key-release: the
> debug key. Instead, it will wait for another key to be pressed,
> indefinitely IIRC.
>
> Just like Jasper said, it is a mistake to use wl_keyboard focus for
> window focus, xdg_shell has a separate mechanism for window focus.
> Window focus is a shell concept IMO, anyway.

The only problem with that is that apps using wl_shell can only use
the keyboard focus as the window focus. Do we just say "too bad,
wl_shell is broken"?

>
> I would favor the proper keyboard focus transitions I described above,
> rather than changing the protocol behaviour. It's easier and can be
> done in compositor only, without fixing all toolkits.
>
> That would be half of the fix, the other half being in Xwayland, right?

Well, there is also the part about triggering the binding on key
release instead of press, only if no other key was pressed in the mean
time. I hope to send the patch(es) for that one of these days.


--
Giulio

>
>
> Thanks,
> pq