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

[Daniel Stone]

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.

Cheers,
Dan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/wayland-devel/attachments/20141120/b6eb0a82/attachment.html>