<div dir="ltr">Hi Bill, and thanks a lot for your comments,<br><br>"What about "raise"?"<br><br>I think the issue with "raise" was the same that with "set_unminimized" or "activate" ; it gives the false impression that the surface will consistently be brought to the foreground (whereas it depends on many things, and will in fact be rare).<br><br>"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>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."<br><br>You have a good point here. Ideally we would catch the very moment the user clicks on the application icon, or starts it in a command line ; Jasper pointed out a X11-specific variable named "DESKTOP_STARTUP_ID" (1) which seems to do this very thing.<br><br>This kind of variable could be filled by the launcher, caught by the shell, and then seamlessly passed to the client (I personally wanted to avoid over-engineering things in preliminary patches). <br><br>"'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."<br><br>Yes this is also a good point ; good you're mentioning that in that simple way !<br><br>"Rather than per-surface I think it would be per-seat."<br><br>The current patch implementation makes it per-client, but in the end you're right. We would only need to remember a few of the latest serials issued by each input interface(keyboard/pointer/touch).<br><br>(1) : <a href="http://lists.freedesktop.org/archives/wayland-devel/2014-August/016279.html">http://lists.freedesktop.org/archives/wayland-devel/2014-August/016279.html</a><br></div><div class="gmail_extra"><br><div class="gmail_quote">2015-03-03 22:15 GMT+01:00 Bill Spitzak <span dir="ltr"><<a href="mailto:spitzak@gmail.com" target="_blank">spitzak@gmail.com</a>></span>:<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>
<br>
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>
<br>
<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.<span class=""><br>
<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><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>