<div dir="ltr">Right.<div class="gmail_extra"><br><div class="gmail_quote">On 20 November 2014 20:37, Bill Spitzak <span dir="ltr"><<a href="mailto:spitzak@gmail.com" target="_blank">spitzak@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On 11/20/2014 12:05 AM, Daniel Stone wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
As far as I can tell from what the others are saying - which I'd totally<br>
agree with - is that wl_keyboard's focus would be much more transient<br>
than it is now, reflecting where keyboard events are _actually_ being<br>
delivered _right now_. So if the compositor took a long-lived grab, e.g.<br>
for the lock screen, you'd lose keyboard focus as you do today, as well<br>
as losing xdg_shell focus. But if the compositor just took an ephemeral<br>
grab (e.g. key binding), then while you would lose keyboard focus, you<br>
wouldn't lose xdg_shell focus.<br>
<br>
So think of keyboard focus as tightly bound to actual event delivery at<br>
that very particular moment in time, and a hint that keys may be pressed<br>
underneath you, so you could well come back with pressed keys you<br>
shouldn't take action on, whereas shell focus is what you'd use to drive<br>
things like rendering your decorations with (in)active highlights.<br>
</blockquote>
<br></span>
So basically you have two events that the client must not respond to!<br></blockquote><div><br></div><div>No. What on earth makes you think that?</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
One of them is now the "the key map changed" event.</blockquote><div><br></div><div>Which you respond to by updating your internal state. Not useless.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">And the other is "a useless event that must be sent before the key map changed event".<br></blockquote><div><br></div><div>Which you respond to by ceasing _all_ actions related to your current keyboard state, such as cancelling key repeat. So, also not useless.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
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!<br></blockquote><div><br></div><div>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?</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
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:</blockquote><div><br></div><div>It's not pointless, so no.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
I can actually see them failing, tbh. Every time we change enter/leave<br>
semantics under X11, we very subtly break quite a lot of clients, which<br>
have more strict requirements on these events than you'd think/hope - I<br>
spent years being bitterly disappointed (mostly on Peter's behalf). That<br>
we strictly pair enter/leave events is IMO effectively part of the<br>
contract we have with clients, and I guarantee you some are relying on a<br>
strict pairing.<br>
</blockquote>
<br></span>
You are WRONG here. ALL the problems I have had with X11 changes are due to you guys enforcing useless pairing of events.<br></blockquote><div><br></div><div>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.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
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.<br></blockquote><div><br></div><div>I don't know where this came from, but it's both massively unrelated, and incorrect.</div><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>Onwards.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
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!<br></blockquote><div><br></div><div>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.</div><div><br></div><div>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.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
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.</blockquote><div><br></div><div>I'm ignoring your jump from 'it has effects I don't like' to 'it has no useful effects', because it's ridiculous.</div><div><br></div><div>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.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">I'd hope that this was restricted to modifiers, so we could just say as<br>
a general rule that the compositor will drive modifier-only hotkeys<br>
(Exposay, layout switch) on release, but all others on press. So if you<br>
have ambiguous hotkey combinations which involve non-modifier keys,<br>
well, you lose.<br>
</blockquote>
<br></span>
Yes restricting this behavior to modifiers makes sense. This does match what clients do and therefore will inter-operate.</blockquote><div><br></div><div>Good.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">The problem was the previous example was talking about a non-modifier. Those should not act different than any client would do.<br>
<br>
So here is an example where "Mod" is a server shortcut:<br>
Here is what happens if "Mod+x" is a shortcut handled by the client:<br>
Here is what happens if "Mod+s" is a shortcut handled by server:<br>
[snip]<br></blockquote><div><br></div><div>These are all correct.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
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).<br>
</blockquote></div><br></div><div class="gmail_extra">Thanks for this totally useless information.</div><div class="gmail_extra"><br></div><div class="gmail_extra">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.</div><div class="gmail_extra"><br></div><div class="gmail_extra">Have a great weekend.</div></div>