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

[Bill Spitzak]

On 11/20/2014 12:05 AM, Daniel Stone wrote:

> 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.

So basically you have two events that the client must not respond to!

One of them is now the "the key map changed" event. And the other is "a 
useless event that must be sent before the key map changed event".

I don't need a "hint that keys may be pressed underneath you". I KNOW 
"keys were pressed underneath me" when I get a focus-in event with the 
key map changed!

I would get rid of this pointless complexity and restore these events to 
their original purpose, which was to instruct clients to update their 
display to show that they are receiving keyboard focus. And I would 
allow the redundant one, because I think your attempts to "pair" events 
are making things worse. And I have real experience in this due to 
changes that you may have been responsible for in X11:

> 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.

You are WRONG here. ALL the problems I have had with X11 changes are due 
to you guys enforcing useless pairing of events.

In particular I must now peek ahead in the event queue on every key up 
in order to detect if it is a fake key-up due to a repeat key. That 
change broke hundreds of applications and toolkits including the 
software I was working on (it basically broke every program using keys 
as modifiers). A very useful program called Amazon Paint had to be 
abandoned because of this and forced all work to be moved from Unix to 
Windows and Photoshop used instead, at tremendous cost and immense harm 
to the future of Linux. So don't you dare claim you are trying to not 
break clients. Somebody panicked about "mispairing of events" and went 
nuts and broke far more software and caused more damage than they could 
ever have imagined.

In addition in all versions of X I have to peek ahead on all exit events 
to see if it is due to an enter into another window that my client owns, 
to avoid blinking in my redrawing. This is stupid and would be trivial 
to fix by sending the enter event first, or not sending the exit event. 
But because somebody seems to think some perverse piece of software will 
crash because the events are not "paired", both the client and server 
software have to be made much more complicated!

Sorry, please stop this. Try writing some clients. The pairing is 
absolutely useless, incredibly TRIVIAL for a client to work around, and 
complicates every layer of your software needlessly. Stop it.

>     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.

Yes restricting this behavior to modifiers makes sense. This does match 
what clients do and therefore will inter-operate. The problem was the 
previous example was talking about a non-modifier. Those should not act 
different than any client would do.

So here is an example where "Mod" is a server shortcut:

   Mod down -> send key Mod down

   Mod up -> execute the shortcut, send redundant focus-in with keymap 
with mod key removed. Notice that no UP event is sent.

Here is what happens if "Mod+x" is a shortcut handled by the client:

   Mod down -> send key Mod down

   'x' down -> send key 'x' down (client may do something with it)

   Mod up -> not a shortcut, send Mod up to client

Here is what happens if "Mod+s" is a shortcut handled by server:

   Mod down -> send key Mod down

   's' down -> execute the shortcut, send redundant focus-in with keymap 
with 's' key added.

   's' up -> send 's' up to client

What I have done in software supporting user-definable keybindings is at 
a low level it produces messages for modifiers when they are released 
with no other changes since they were pressed. It produces messages for 
all other keys on down. This allows all the shortcuts, including the 
shift keys, to be in the same table. This exactly matches what event is 
eaten by the shortcut-handling server (the down events for normal keys 
and the up events for modifiers).