<div dir="ltr"><div>Hi Jasper,<br><br>"This is not an "I need attention" request. Perhaps our documentation is poor."<br></div>You are right, just as I answered to Jonas, I mixed present() with the desktop-launcher-focus-stealing feature we were discussing in the previous thread. Sorry for the confusion.<br></div><div class="gmail_extra"><br><div class="gmail_quote">2015-03-09 3:25 GMT+01:00 Jasper St. Pierre <span dir="ltr"><<a href="mailto:jstpierre@mecheye.net" target="_blank">jstpierre@mecheye.net</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote"><div><div class="h5">On Sun, Mar 8, 2015 at 6:57 PM, Jonas Ådahl <span dir="ltr"><<a href="mailto:jadahl@gmail.com" target="_blank">jadahl@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 Fri, Feb 27, 2015 at 11:14:19AM +0100, Manuel Bachmann wrote:<br>
> Hello fellow developers,<br>
><br>
> I just wanted to continue a discussion which occured some time ago, about<br>
> the eventuality of adding a "xdg_surface_present()" request to XDG-Shell.<br>
><br>
> (For reference, former discussion entry points are here :<br>
> <a href="http://lists.freedesktop.org/archives/wayland-devel/2014-July/016078.html" target="_blank">http://lists.freedesktop.org/archives/wayland-devel/2014-July/016078.html</a><br>
> <a href="http://lists.freedesktop.org/archives/wayland-devel/2014-July/016224.html" target="_blank">http://lists.freedesktop.org/archives/wayland-devel/2014-July/016224.html</a><br>
> <a href="http://lists.freedesktop.org/archives/wayland-devel/2014-August/016269.html" target="_blank">http://lists.freedesktop.org/archives/wayland-devel/2014-August/016269.html</a>)<br>
><br>
> To summarize : the idea behing "xdg_surface_present()" is that there are<br>
> some cases where a surface wants to advertise the fact that it has been<br>
> updated and the user may want to take a look (think of an IRC chat window<br>
> which gets new messages containing the user's nickname). There are even<br>
> some corner cases where the surface may want to be raised and focused<br>
> directly ; but we do not want to request to be abused this way, a client<br>
> must be prevented from stealing the focus repeatedly. At last, the<br>
> compositor's shell should have the last word.<br>
<br>
</span>I have some comments I thought I'd share. See the inline replies:<br>
<span><br>
><br>
> Here are some of the points that were discussed and the outcomes :<br>
><br>
> - Pekka Paalanen pointed out the request name was unclear and suggested to<br>
> use "xdg_surface_needs/wants_attention()" instead. Jasper St. Pierre<br>
> pointed out that "_NET_WM_STATE_DEMANDS_ATTENTION" already existed in X11<br>
> and does not do the same thing. We discussed that again yesterday and<br>
> thought that present() fitted nicely ;<br>
<br>
</span>There is also the "The Present Extension" in X11, so is "present" really<br>
that much better? If the use case is a client wants attention because<br>
some reason (be it IRC highlight, new message, task finished or<br>
whatever), shouldn't the request name contain that information some how?<br>
Isn't what is discussed here even quite similar to<br>
"_NET_WM_STATE_DEMANDS_ATTENTION"?<span><br></span></blockquote><div><br></div></div></div><div>No. It's equivalent to the _NET_ACTIVATE_WINDOW ClientMessage.<br><br></div><div>IRC highlights, new messages, task finished, etc. are use cases for notifications. The use case here is "user double-clicked on a file and I want my existing gedit window to be raised in response". Basically, places where you want to show the window immediately if the stars are aligned correctly (the serial is correct).<br></div><span class=""><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span>
><br>
> - We want to implement focus stealing prevention : if the user is starting<br>
> a slow app (browser...), gets back to typing a mail while it starts, and at<br>
> last the browser window appears, the focus should stay in the mail window<br>
> without his keyboard presses going elsewhere ;<br>
<br>
</span>This rather sound like something startup notification protocol related<br>
than an "I need attention" request, and I think that problem needs to be<br>
tackled separately.<span><br></span></blockquote><div><br></div></span><div>This is not an "I need attention" request. Perhaps our documentation is poor.<br></div><div><div class="h5"><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span>
><br>
> - Implementing focus stealing prevention between different clients may be<br>
> easy : just count the delay between the client has been started and its<br>
> shell surface actually gets mapped, and if it has been too long and the<br>
> focus is elsewhere, show the surface without focusing it (but with a<br>
> notification). The notion of "the client has been started" is vague, but at<br>
> worst, we can use the time when the client did its initial connection to<br>
> the compositor ;<br>
<br>
</span>As Bill mentioned, clients that happens to do a lot of things before<br>
connecting will have a very short time from that the connection is<br>
established to that a surface is to be mapped. It can even be trivially<br>
abused to steal focus at unexpected times.<br>
<span><br>
><br>
> - Within a same client application, however, it is harder. Think of a<br>
> browser where you click "new window" but lots of time pass before it<br>
> appears. The "starting point" is the pointer click event. So the idea would<br>
> be to pass the Wayland serial corresponding to this event :<br>
> "xdg_surface_present (surface, <SERIAL>)". It the serial has been issued<br>
> too long ago, do focus stealing prevention.<br>
<br>
</span>Serials are quite easy to guess, but for intra-client focus switching it<br>
might work. I don't think it's a good idea to pass serials between<br>
clients and assume they have any effect, and the server should probably<br>
not allow such focus switching between clients.<br>
<span><br>
><br>
> This raises the question : how do we say "We have no serial to pass", for<br>
> the standard case ? We repeatedly suggested 0 ("xdg_surface_present<br>
> (surface, 0)") because serials are incrementing globals, so "0" to be<br>
> issued would be very-very unlikely. Should we formalize that somewhere in<br>
> the protocol ?<br>
<br>
</span>If 0-is-invalid its not formalized, it should not be relied upon IMO,<br>
but I think it is useful to have a non-valid serial.<br>
<br>
<br>
Jonas<br>
<span><br>
><br>
> (Having 2 requests, one with serial and one without, has been suggested by<br>
> krh on IRC ; I personally prefer only one request because they would serve<br>
> the same purpose, but why not ? It would get the need for formalization out<br>
> of the way)<br>
><br>
> We also want to secure the request from garbage random serials ; the<br>
> implementation behavior is that there is only one serial valid for a few<br>
> seconds, if the surface has not been focused for some time, it will not be<br>
> able to raise itself even if it random()ly finds the formerly "good" serial.<br>
><br>
> -----<br>
> Now the demos ! Here is the latest code :<br>
><br>
> <a href="https://github.com/Tarnyko/weston-xdg_surface_present/commits/test" target="_blank">https://github.com/Tarnyko/weston-xdg_surface_present/commits/test</a><br>
><br>
> A video for the generic "focus stealing prevention" case (delayed start,<br>
> focus stays in old surface) between different clients :<br>
><br>
> <a href="https://www.youtube.com/watch?v=gifjXyPV3X4" target="_blank">https://www.youtube.com/watch?v=gifjXyPV3X4</a><br>
><br>
> and within the same client :<br>
><br>
> <a href="https://www.youtube.com/watch?v=Xiq1p5AOf1U" target="_blank">https://www.youtube.com/watch?v=Xiq1p5AOf1U</a><br>
> -----<br>
><br>
> Any thoughts on this ?<br>
><br>
> --<br>
> Regards,<br>
><br>
><br>
><br>
</span>> *Manuel BACHMANN Tizen Project VANNES-FR*<br>
<div><div><br>
> _______________________________________________<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>
_______________________________________________<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>
</div></div></blockquote></div></div></div><span class="HOEnZb"><font color="#888888"><br><br clear="all"><br>-- <br><div>  Jasper<br></div>
</font></span></div></div>
</blockquote></div><br><br clear="all"><br>-- <br><div class="gmail_signature"><div dir="ltr"><font>Regards,<br>
<br>
<i><b>Manuel BACHMANN</b><br>
Tizen Project<br>
VANNES-FR</i><br>
</font></div></div>
</div>