<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">Manuel,<br></div><div class="gmail_quote">Thanks for keeping this going.  I don't have a whole lot of comments at the moment as it's a pretty small protocol change.  I would like to hear some commentary from Jasper and some of the other desktop devs though.<br><br>The one comment I will make about the protocol is that you may want to change the documentation a bit.  Instead of specifying that it must be an interactive gui notification that allows the user to bring up the window. It might be better to simply specify that the window has new content and would like the compositor to notify the user.<br></div><div class="gmail_quote"><br>On Tue, Mar 3, 2015 at 1:15 PM, 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 class=""><br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
- Pekka Paalanen pointed out the request name was unclear and suggested<br>
to use "xdg_surface_needs/wants_<u></u>attention()" instead. Jasper St. Pierre<br>
pointed out that "_NET_WM_STATE_DEMANDS_<u></u>ATTENTION" already existed in<br>
X11 and does not do the same thing. We discussed that again yesterday<br>
and thought that present() fitted nicely ;<br>
</blockquote>
<br></span>
What about "raise"?<span class=""><br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
- Implementing focus stealing prevention between different clients may<br>
be easy : just count the delay between the client has been started and<br>
its shell surface actually gets mapped, and if it has been too long and<br>
the 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<br>
at worst, we can use the time when the client did its initial connection<br>
to the compositor ;<br>
</blockquote>
<br></span>
I suspect that initial connection is going to be far too late. It will be after all the dynamic linking and static object initialization and script interpretation (imagine if the wayland api is written in the interpreted language, it will not open the display until quite a lot of interpretation is done), all of which are the real reason modern apps take forever to start up.<br></blockquote><div><br></div><div>Yes, launching another client is quite possibly going to take a long time.  Some clients are written in C and will start in less than a second.  Other, heavier clients may take substantially longer.  External processes will most likely time out. <br></div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
I would put the serial somewhere that the app can get it, perhaps in an environment variable, so it can send it with it's first raise request.<span class=""><br></span></blockquote><div><br></div><div>I'm not entirely convinced that serials are the right way to do cross-client focus stealing prevention.  However, I'm open to the idea. <br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
- Within a same client application, however, it is harder.<br>
</blockquote>
<br></span>
Actually it is impossible without a serial. The serial is the correct solution which makes within the same client easier that between clients.<span class=""><br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
This raises the question : how do we say "We have no serial to pass",<br>
for 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<br>
in the protocol ?<br>
</blockquote>
<br></span>
'0' is useful but should force the "the serial is too old" behavior. Anybody who wants a real raise will have to get an actual serial.</blockquote><div><br></div><div>By that, do you mean that a serial of 0 should mean "Don't raise just flash/bounce/whatever"?  If that's the case, then I think I would agree.<br><br>It seems that there are three distinct use-cases here:<br><br></div><div> 1) The client wants to gently alert the user (serial of 0).<br></div><div> 2) The client wants to raise a window (real serial).<br></div><div> 3) The client doesn't have a serial.<br></div><div><br></div><div>I don't know what I think about special-casing 0.  I don't see any problem with doing so at the moment.  If we were particularly concerned about it, it would be easy enough to ensure that the serial 0 is never handed out.  What I'm more concerned about is that there are two different cases in which we don't have a valid serial.  If we're intending to have this be something that the client calls when it wants attention after it's first been opened, then this third case may be something we have to consider.  For example, if you run a client on the command-line and give it a file to open.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
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<br>
be able to raise itself even if it random()ly finds the formerly "good"<br>
serial.<br>
</blockquote>
<br></span>
It seems to me the compositor will have to remember very few serials. Rather than per-surface I think it would be per-seat. And there would be no timeout, instead it would remember the last N button or key presses (N quite possibley is 1).<br></blockquote><div><br></div><div>Yes, per-seat is most likely what we want.  How many serials do we want to hold on to?  I think that's kind of depends on how badly we want to pass serials across clients.  Within a client, one is probably sufficient.  If we're going to pass it between clients, we probably want to hold on to more and have a timeout.  We probably also want to do something such as clearing all serials when the user raises a window.  However, that falls under the category of heuristics, not protocol.<br></div></div></div></div>