<div dir="ltr">Hi,<div class="gmail_extra"><br><div class="gmail_quote">On 19 November 2014 21:05, 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/19/2014 05:08 AM, Pekka Paalanen wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Just like Jasper said, it is a mistake to use wl_keyboard focus for<br>
window focus, xdg_shell has a separate mechanism for window focus.<br>
Window focus is a shell concept IMO, anyway.<br>
</blockquote></blockquote></blockquote>
<br></span>
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.<br>
<br>
Unless your goal is to make point-to-type impossible?</blockquote><div><br></div><div>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.</div><div><br></div><div>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.</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"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
The only problem with that is that apps using wl_shell can only use<br>
the keyboard focus as the window focus. Do we just say "too bad,<br>
wl_shell is broken"?<br>
</blockquote>
<br>
Yup. I think that's a reasonable thing to do. It's meant to be phased<br>
out even though we can "never" drop it completely. (except mutter<br>
already did, IIRC).<br>
<br>
It's not *that* bad. At worst, it's a flicker. At best, might not even<br>
be visible.<br>
</blockquote>
<br></span>
The *title bar* will flicker. I think that is pretty bad.<br></blockquote><div><br></div><div>I agree that it's not ideal.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
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!<br></blockquote><div><br></div><div>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.</div><div><br></div><div>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. :\</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
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!</blockquote><div><br></div><div>Heh. To be fair, these debug shortcuts are pretty ephemeral - things like screenshots, </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"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Well, there is also the part about triggering the binding on key<br>
release instead of press, only if no other key was pressed in the mean<br>
time. I hope to send the patch(es) for that one of these days.<br>
</blockquote></blockquote>
<br></span>
No! Users do NOT want this. Keys take action when you push them. Otherwise the interface looks slow and drives users crazy.</blockquote><div><br></div><div>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.</div><div><br></div><div>Another classic example is Ctrl+Shift used to drive layout change (this is the Windows default), when you still want Ctrl+Shift shortcuts.</div><div><br></div><div>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.</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">
Mod down -> send key Mod down<br>
's' down -> oooh, hotkey, steal kbd focus, send kbd.leave<br>
<br>
Then either<br>
<br>
's' up -> do screenshot, restore kbd focus, send kbd.enter with Mod<br>
down.<br>
<br>
or<br>
<br>
'x' down -> not our hotkey after all, restore kbd focus, send kbd.enter<br>
with Mod down, send key 'x' down<br>
</blockquote>
<br></span>
I think you meant the kbd.enter would include the Mod *and* the 's' key.<br></blockquote><div><br></div><div>Yes.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
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:</blockquote><div><br></div><div>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.</div><div><br></div><div>Cheers,</div><div>Dan </div></div></div></div>