<div dir="ltr">Hi,<div class="gmail_extra"><br><div class="gmail_quote">On 20 November 2014 08:05, Daniel Stone <span dir="ltr"><<a href="mailto:daniel@fooishbar.org" target="_blank">daniel@fooishbar.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><span class="">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>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></span><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></div></blockquote><div><br></div><div>I should add that none of this precludes point-to-type/sloppy-focus. The focus remains entirely at the discretion of the compositor, and this makes it no more or less difficult than it is today: just adds another focus annotation which better accounts for ephemeral focus changes.</div><div><br></div><div>Cheers,</div><div>Dan </div></div></div></div>