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

[Daniel Stone]

Right.

On 20 November 2014 20:37, Bill Spitzak <spitzak at gmail.com> wrote:

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

No. What on earth makes you think that?


> One of them is now the "the key map changed" event.


Which you respond to by updating your internal state. Not useless.


> And the other is "a useless event that must be sent before the key map
> changed event".
>

Which you respond to by ceasing _all_ actions related to your current
keyboard state, such as cancelling key repeat. So, also not useless.


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

And in the meantime, you've just repeated whatever keys were down when the
focus left for the entire time. Sounds great, where do I sign up?


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


It's not pointless, so no.


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

I assume by 'you guys', you mean 'the guys who wrote the X11 spec whilst I
was less than a year old'. And since the spec requires it, enforcing it is
required for compilance with the spec, therefore it is not useless. Even if
it didn't have any other use, which it does. But let's continue.


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

I don't know where this came from, but it's both massively unrelated, and
incorrect.

The way you detect repeat in _core_ X11, is by a stream of paired KeyPress
and KeyRelease events. Look it up. Clients rely on this, and conformance
relies on it too. I don't know if you've heard of an extension called the X
Keyboard Extension (obscure name, I know), but since its inclusion in
X11R6.1 in 1996, the XkbSetDetectableAutorepeat function has allowed you to
request key repeat be sent as a stream of press-press-press-press-release
events, rather than press-release-press-release-press-release. For bonus
points, it's even part of the core libX11.so.6 API/ABI. And it works
perfectly, and every real toolkit I've seen has made good use of it.

So I don't know who took the decision to not use a toolkit but instead
write their own, to write a toolkit without seemingly looking at any prior
art, or to apparently abandon an entire product on the basis that peeking
ahead in the event stream was more difficult than five minutes on Google,
but this is a person who should so comprehensively not be in charge of a
software product that whatever they were running would've been doomed
regardless.

This is not something which has ever changed in X11, ever. It's not a
recent development that someone panicked and changed the X server to do it;
it's the same behaviour we've had since 1987, in which time people have
worked out how to deal with it. Or most people, anyway.

Onwards.


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

That 'somebody' would again be the people who wrote the spec that people
rely on. How do we know that people rely on it? Because some pretty fiddly
bugs crept in after MPX, and a _lot_ of people complained to RHEL that
their apps broke, and Peter had to fix it. This probably went on for about
five years before all of them were properly stomped out.

I agree it would be nice to have a notification that it's going to a
surface owned by the same client, mind. It's something I've got on my todo
list to fix, but your combination of furious, insulting, condescending, and
(perhaps worst of all) totally flat-out incorrect, is not really motivating
me to fix it.


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


I'm ignoring your jump from 'it has effects I don't like' to 'it has no
useful effects', because it's ridiculous.

I'm also ignoring your request to 'write some clients', because I've done
it for years now (three toolkits, three EGL stacks, a browser, a media
framework, so on, so forth). On the other hand, you prove almost every
single thread that you have never ever written a single client in your
life. Not only do you not understand any of the fundamentals of the Wayland
protocol - things which are obvious to anyone who's ever written any client
more complicated than wl_display_connect(); exit(); - but apparently you
don't particularly understand how X works either.


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


Good.


> 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:
> Here is what happens if "Mod+x" is a shortcut handled by the client:
> Here is what happens if "Mod+s" is a shortcut handled by server:
> [snip]
>

These are all correct.


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

Thanks for this totally useless information.

I didn't want to reply to this mail, since not only does it contribute
absolutely nothing of value to a thread which is already borderline
impossible to get through, but is incredibly rude and insulting. On the
other hand, it was so full of absolute fiction that I felt compelled to,
lest someone stumble on it in the archives one day and think any of it (bar
the small bit at the end) made even the smallest amount of sense.

Have a great weekend.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/wayland-devel/attachments/20141121/523e6b79/attachment-0001.html>