<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Fri, Nov 1, 2013 at 11:36 PM, Jasper St. Pierre <span dir="ltr"><<a href="mailto:jstpierre@mecheye.net" target="_blank">jstpierre@mecheye.net</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">On Fri, Nov 1, 2013 at 11:58 PM, Jason Ekstrand <span dir="ltr"><<a href="mailto:jason@jlekstrand.net" target="_blank">jason@jlekstrand.net</a>></span> wrote:<br>
<div><br></div><div>... snip<br></div><div class="im"><div> </div><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">Gregory,<br>
Thank you very much for your e-mail. I think that helps a lot. The lack of code is ok because I think Rafael is planning to start implementing as soon as things settle a bit. Sometimes protocol discussions can end up with a whole lot of hypotheticals and what you gave was a very clear concise discussion of the topic.<br>
<br></div><div>If I am understanding you correctly, what we need are an "activate" request and "notify_active" and "notify_inactive" events. To support sloppy focus, clients should just always try to activate on wl_pointer.enter and let the compositor sort it out unless they have a good reason to do otherwise. For cases such as alt-tab, or another window closing, the compositor simply sends a notify_active. I think I'm ok with this.<br>
<br></div></div></blockquote><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">Two more questions that come to mind:<br><br></div>
<div class="gmail_extra">1) Will we ever need a deactivate request? Under the given scheme, no need comes immediately to mind.<br></div></div></blockquote><div><br></div></div><div>No. Well, if we need it, let's add it later.<br>
<br></div><div class="im"><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><div class="gmail_extra">
2) Should the activate be associated with a particular seat. If you have multiple cursors, you can easily have multiple active windows so this seems perfectly reasonable. If this is the case, should this be part of wl_seat or should we keep it in xdg_shell? I'm a little afraid to clutter wl_seat unnecessarily but this is very quickly starting to look like a seat focus.<br>
</div></div></blockquote><div><br></div></div><div>I don't think windows need to know which seat they're active on, only that they're active on possibly one of them. From my eyes, there's nothing that prevents the compositor to send "notify_active" to more than one window at the same time for multiseat support.<br>
<br></div><div>If I click on an unresponsive window A, we'll send a "click" event to that window, but since it's unresponsive, it won't activate. I might then decide to activate another window B, which will respond. When the window A becomes responsive again, it will process the "click" event and decide to send an "activate" request back. We need to make sure that this "rogue" client doesn't steal the focus, so the compositor needs to record the serial for the last "activate" event it got (sent by window B), and compare against it when it gets an "activate" event, besides whatever policies it might have.<br>
</div></div></div></div></blockquote><div><br></div><div>Here is the problem. Say you have two pointers P and Q and two and two windows A and B. P clicks on A and A a is now active. Q clicks on B and now B is active. Then P goes and clicks on B. However, B is already active so it doesn't request an activation and A stays active with pointer P. This assumes we are trusting clients to request activation. The other option is that we simply force a click-always-activates model and clients are constantly fighting the compositor just to make modal dialogues work.<br>
</div><div> </div><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"><div>
<br></div>But serials are seat-specific, so we need the "activate" request to relay the seat back for the purposes of validating the timestamp. I don't think it makes sense to expose the active window on wl_seat, though.<br>
</div></div></div></blockquote><div><br></div><div>That's not correct. Timestamps are seat specific but timestamps are not the same as serials. Timestamps are local to the seat. Serials are actually compositor-global in weston and, in order to make things work, should probably at least be client-global in other compositors.<br>
</div><div> </div><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">
<br><div></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im"><div dir="ltr"><div class="gmail_extra">Once again, Gregory, Thanks for the explanation. I hope I'm following ok.<span><font color="#888888"><br>
</font></span></div><span><font color="#888888"><div class="gmail_extra">--Jason Ekstrand<br></div></font></span></div>
<br></div><div class="im">_______________________________________________<br>
wayland-devel mailing list<br>
<a href="mailto:wayland-devel@lists.freedesktop.org" target="_blank">wayland-devel@lists.freedesktop.org</a><br>
<a href="http://lists.freedesktop.org/mailman/listinfo/wayland-devel" target="_blank">http://lists.freedesktop.org/mailman/listinfo/wayland-devel</a><br>
<br></div></blockquote></div><span class="HOEnZb"><font color="#888888"><br><br clear="all"><br>-- <br> Jasper<br>
</font></span></div></div>
</blockquote></div><br></div></div>