<div dir="ltr">Hi,<div class="gmail_extra"><br><div class="gmail_quote">On 21 November 2014 08:57, Pekka Paalanen <span dir="ltr"><<a href="mailto:ppaalanen@gmail.com" target="_blank">ppaalanen@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="HOEnZb"><div class="h5">On Thu, 20 Nov 2014 10:31:18 +0200<br>
Giulio Camuffo <<a href="mailto:giuliocamuffo@gmail.com">giuliocamuffo@gmail.com</a>> wrote:<br>
> 2014-11-20 10:05 GMT+02:00 Daniel Stone <<a href="mailto:daniel@fooishbar.org">daniel@fooishbar.org</a>>:<br>> > On 19 November 2014 21:05, Bill Spitzak <<a href="mailto:spitzak@gmail.com">spitzak@gmail.com</a>> wrote:<span style="color:rgb(34,34,34)"> </span></div></div></blockquote><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="HOEnZb"><div class="h5"><span style="color:rgb(34,34,34)">> >> You also mentioned an "enter debug mode" shortcut. That must NOT send a</span><br></div></div><span class="">
> >> focus-out event, as it could change the state of the client being debugged!<br>
<br>
</span>By the very same reasoning, nothing about the debug key combo should be<br>
sent to any client - except that's not possible. Right now the debug<br>
key works by first hitting Mod+Shift+Space, then hitting the actual<br>
debug key (a letter key usually). At least the Mod and Shift will<br>
somehow end up in some client.</blockquote><div><br></div><div>Shrug, so be it. Not a lot we can do about it, and this is also the case on other OSes.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">
> > Heh. To be fair, these debug shortcuts are pretty ephemeral - things like<br>
> > screenshots,<br>
<br>
</span>Our debug things include tinting all GL-composited stuff green, drawing<br>
the triangle mesh edges, toggling cursor and overlay planes of DRM, etc.</blockquote><div><br></div><div>I know, I use them all the time. :) I mean ephemeral in terms of keyboard focus - the grab is active for one press, and focus then reverts to the client - rather than ephemeral in terms of effect.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">
> > I agree 100%. Again, think of nesting compositors: why should our compositor<br>
> > behave completely different if it's nested? The more difficult we make it to<br>
> > sensibly nest compositors, the more we're shooting ourselves in the foot.<br>
><br>
> Ok, now you got me confused. Wasn't this what you said would be the<br>
> correct way to handle bindings?<br>
<br>
</span>Yeah, I'm confused too.<br>
<br>
I tried to think of a stack of:<br>
        evdev <- Weston <- nested (compositor) <- app<br>
and the different cases of how Weston behaves towards nested vs. OS<br>
(e.g. VT-switching) behaves towards Weston, and I'm not sure I see what<br>
nested would need to do differently from weston with what I thought.<br></blockquote><div><br></div><div>I tried to write out the case that made me nervous in my head, but couldn't. I'm not sure if that's because it's not actually a real problem, or I'm just far too tired.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
So how should it work?<br>
<br>
I would still assume, that if I press Mod+s to take a screenshot, I<br>
wouldn't want the 's' to appear on the terminal that happened to have<br>
the keyboard focus when Mod went down. If the terminal had a Mod+s<br>
shortcut too, should it run or not?<br>
<br>
That is, if all of Weston, nested, and app happened to have the same<br>
shortcut, should all three fire, or only Weston's?<br></blockquote><div><br></div><div>Only Weston.</div><div><br></div><div>All three need to obey the same rule:</div><div>  - when triggering a hotkey, steal the focus and do _not_ send key events</div><div>  - when the grab is ended, send the focus back to the client with the true, correct, and full keyboard state in enter</div><div>  - on an enter event, update internal state but do _not_ trigger actions or hotkeys because of it</div><div><br></div><div>Cheers,<br></div><div>Daniel</div></div></div></div>