<div dir="ltr"><div><div>Hi everybody again,<br><br></div>As there does not seem to be a great motivation to annotate the protocol,  I suppose the right way to go is to have the 2 requests.<br><br></div><div>I prepared the patches in this sense, and am going to push them for review right now.<br></div><div><br></div><div>Regards,<br></div><div>Manuel<br></div></div><div class="gmail_extra"><br><div class="gmail_quote">2015-03-27 6:54 GMT+01:00 Manuel Bachmann <span dir="ltr"><<a href="mailto:manuel.bachmann@open.eurogiciel.org" target="_blank">manuel.bachmann@open.eurogiciel.org</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><div>Hi Jasper, Jonas, Pekka, Jason, <br><br></div><div>Just a little update regarding the present() request. As the serial thing seems to be our main concern, aside from the minor protocol change and new functionality we mostly seem to agree on, here are the 2 ways we could do it :</div><div><br></div><div>1) modify the protocol, which means :<br></div><div>- in the XML, adding : "A serial of 0 cannot be returned by the compositor ; thus in requests, passing 0 as a "serial" parameter actually means no specific serial is needed nor provided."<br></div><div>- modify wayland-server to reflect the description (thanks to Jonas for reminding me).<br><br></div><div>2) have 2 requests instead of 1 :<br></div><div>xdg_surface_present(struct xdg_surface *surface);<br></div><div>xdg_surface_present_from_event(struct xdg_surface *surface, uint32_t serial);<br></div><div><br></div><div>What should be our preferred way ? Doing 2) is still satisfying is we cannot do 1). Looking for a consensus here.<br></div><div><br></div>Regards,<br></div>Manuel<div><div class="h5"><br><div><div class="gmail_extra"><br><div class="gmail_quote">2015-03-09 6:17 GMT+01:00 Manuel Bachmann <span dir="ltr"><<a href="mailto:manuel.bachmann@open.eurogiciel.org" target="_blank">manuel.bachmann@open.eurogiciel.org</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div>Hi Jasper,<span><br><br>"This is not an "I need attention" request. Perhaps our documentation is poor."<br></span></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"><div><div><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>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><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><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><font color="#888888"><br><br clear="all"><br>-- <br><div>  Jasper<br></div>
</font></span></div></div>
</blockquote></div><br><br clear="all"><br></div></div><span>-- <br><div><div dir="ltr"><font>Regards,<br>
<br>
<i><b>Manuel BACHMANN</b><br>
Tizen Project<br>
VANNES-FR</i><br>
</font></div></div>
</span></div>
</blockquote></div><br><br clear="all"><br>-- <br><div><div dir="ltr"><font>Regards,<br>
<br>
<i><b>Manuel BACHMANN</b><br>
Tizen Project<br>
VANNES-FR</i><br>
</font></div></div>
</div></div></div></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>