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

[Giulio Camuffo]

2014-11-20 10:05 GMT+02:00 Daniel Stone <daniel at fooishbar.org>:
> Hi,
>
> On 19 November 2014 21:05, Bill Spitzak <spitzak at gmail.com> wrote:
>>
>> On 11/19/2014 05:08 AM, Pekka Paalanen wrote:
>>>>>
>>>>> 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.
>>
>>
>> Can you explain when (except to fix this bug) then "xdg_shell focus" will
>> be set differently than the input device focus? I think you are talking
>> about "activation" which is DIFFERENT than keyboard focus.
>>
>> Unless your goal is to make point-to-type impossible?
>
>
> As far as I can tell from what the others are saying - which I'd totally
> agree with - is that wl_keyboard's focus would be much more transient than
> it is now, reflecting where keyboard events are _actually_ being delivered
> _right now_. So if the compositor took a long-lived grab, e.g. for the lock
> screen, you'd lose keyboard focus as you do today, as well as losing
> xdg_shell focus. But if the compositor just took an ephemeral grab (e.g. key
> binding), then while you would lose keyboard focus, you wouldn't lose
> xdg_shell focus.
>
> So think of keyboard focus as tightly bound to actual event delivery at that
> very particular moment in time, and a hint that keys may be pressed
> underneath you, so you could well come back with pressed keys you shouldn't
> take action on, whereas shell focus is what you'd use to drive things like
> rendering your decorations with (in)active highlights.
>
>>>>
>>>> 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"?
>>>
>>>
>>> Yup. I think that's a reasonable thing to do. It's meant to be phased
>>> out even though we can "never" drop it completely. (except mutter
>>> already did, IIRC).
>>>
>>> It's not *that* bad. At worst, it's a flicker. At best, might not even
>>> be visible.
>>
>>
>> The *title bar* will flicker. I think that is pretty bad.
>
>
> I agree that it's not ideal.
>
>>
>> I also think you are panicking about a non-existent problem. No client is
>> going to fail because it got two focus-in events in a row. Just send two
>> events irregardless of version, and stop adding needless complexity to
>> weston!
>
>
> I can actually see them failing, tbh. Every time we change enter/leave
> semantics under X11, we very subtly break quite a lot of clients, which have
> more strict requirements on these events than you'd think/hope - I spent
> years being bitterly disappointed (mostly on Peter's behalf). That we
> strictly pair enter/leave events is IMO effectively part of the contract we
> have with clients, and I guarantee you some are relying on a strict pairing.
>
> I don't think 'but that's not part of the spec' is really an excuse either.
> If we only allowed clients to rely on what was in the wl_keyboard spec,
> no-one would ever be able to use keyboards at all. :\
>
>>
>> You also mentioned an "enter debug mode" shortcut. That must NOT send a
>> focus-out event, as it could change the state of the client being debugged!
>
>
> Heh. To be fair, these debug shortcuts are pretty ephemeral - things like
> screenshots,
>
>>>>
>>>> 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.
>>
>>
>> No! Users do NOT want this. Keys take action when you push them. Otherwise
>> the interface looks slow and drives users crazy.
>
>
> That sometimes conflicts with the goal of having ambiguous hotkeys. For
> instance, if you press and release Mod on its own, you'll get Exposay mode;
> Mod is, however, also used as the prefix for a million other hotkeys. So in
> that case, we have to arm the shortcut when mod is pressed, disarm/release
> it if any other keys were pressed, and then trigger on release.
>
> Another classic example is Ctrl+Shift used to drive layout change (this is
> the Windows default), when you still want Ctrl+Shift shortcuts.
>
> I'd hope that this was restricted to modifiers, so we could just say as a
> general rule that the compositor will drive modifier-only hotkeys (Exposay,
> layout switch) on release, but all others on press. So if you have ambiguous
> hotkey combinations which involve non-modifier keys, well, you lose.
>
>>>
>>> Mod down -> send key Mod down
>>> 's' down -> oooh, hotkey, steal kbd focus, send kbd.leave
>>>
>>> Then either
>>>
>>> 's' up -> do screenshot, restore kbd focus, send kbd.enter with Mod
>>> down.
>>>
>>> or
>>>
>>> 'x' down -> not our hotkey after all, restore kbd focus, send kbd.enter
>>> with Mod down, send key 'x' down
>>
>>
>> I think you meant the kbd.enter would include the Mod *and* the 's' key.
>
>
> Yes.
>
>>
>> In any case, DO NOT DO THIS!!!! What the above sequence should do is a
>> screenshot, followed by the action of Mod+s+x in the client. This is what
>> users expect and what every toolkit in the world does on every platform.
>> There is nothing special about "compositor shortcuts" and they should NEVER
>> act differently than a client would that handles both shortcuts. Here is
>> correct behavior:
>
>
> I agree 100%. Again, think of nesting compositors: why should our compositor
> behave completely different if it's nested? The more difficult we make it to
> sensibly nest compositors, the more we're shooting ourselves in the foot.

Ok, now you got me confused. Wasn't this what you said would be the
correct way to handle bindings?

>
> Cheers,
> Dan