<div dir="ltr"><div>Hi Jasper, Jason,</div><div> </div><div>"Agreed. Especially if you start an application, but it's slow to start, and you have typed into the current window or have navigated away from it since, you should get a popup instead of the window immediately mapped. This is known as "focus stealing prevention"."</div>
<div> </div><div>Good point. I will work on this.<br></div><div>"Unfortunately, the protocol as Manuel mocked up doesn't have the event timestamp. This is required so we can track when the surface was intended to be presented."</div>
<div> </div><div>Have to get familiar with timestamps, looking for some useful code right now.</div><div> </div><div>"Another question for Manuel: Does present() interact with the surface commit? Should it?"</div>
<div> </div><div>Not in a way that I know of. From a compositor point of view, present() (when the user interacts to show) does only change the surface worskpace, stacking order, and focus. I doesn't trigger a commit, or at least it's unwanted. I think it can be compared to what happens when you cycle through windows with "Mod-Tab" and choose one.</div>
</div><div class="gmail_extra"><br><br><div class="gmail_quote">2014-07-29 23:11 GMT+02:00 Jason Ekstrand <span dir="ltr"><<a href="mailto:jason@jlekstrand.net" target="_blank">jason@jlekstrand.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><br><div class="gmail_quote"><div>On Tue, Jul 29, 2014 at 12:16 PM, Bill Spitzak <span dir="ltr"><<a href="mailto:spitzak@gmail.com" target="_blank">spitzak@gmail.com</a>></span> wrote:<br>
<blockquote style="margin:0px 0px 0px 0.8ex;padding-left:1ex;border-left-color:rgb(204,204,204);border-left-width:1px;border-left-style:solid" class="gmail_quote"><div>On 07/29/2014 11:40 AM, Manuel Bachmann wrote:<br>
<br>
<blockquote style="margin:0px 0px 0px 0.8ex;padding-left:1ex;border-left-color:rgb(204,204,204);border-left-width:1px;border-left-style:solid" class="gmail_quote">
When creating a xdg_surface, the surface will not be mapped (i.e. shown)<br>
by desktop-shell anymore. It will only be if xdg_surface_present() has<br>
been called once.<br>
</blockquote>
<br></div>
There seems to be a design goal in Wayland to prevent clients from making surfaces that they never map. So it would be better if creation + commit of a surface did the same thing as present. Also this does not break existing clients.<br>
</blockquote><div><br></div></div><div>That's the way it has worked in the past. There's nothing requiring this behavior in xdg_shell as we haven't stabilized it fully yet. Really, it doesn't matter whether the client has to call an additional request beyond just creating the xdg_surface.<br>
<br></div><div>Another question for Manuel: Does present() interact with the surface commit? Should it?<br></div><div><div> </div><blockquote style="margin:0px 0px 0px 0.8ex;padding-left:1ex;border-left-color:rgb(204,204,204);border-left-width:1px;border-left-style:solid" class="gmail_quote">
<br>
There is nothing special about the first time the surface wants attention (other than historical legacy). The desktop should be allowed to turn this into a notification just like it would on subsequent calls.<div><br></div>
</blockquote><div><br></div></div><div>True. We shouldn't claim to guarantee any "window showing up behavior" on the first or subsequent calls.<br> <br></div><div><blockquote style="margin:0px 0px 0px 0.8ex;padding-left:1ex;border-left-color:rgb(204,204,204);border-left-width:1px;border-left-style:solid" class="gmail_quote">
<div>
<br>
<blockquote style="margin:0px 0px 0px 0.8ex;padding-left:1ex;border-left-color:rgb(204,204,204);border-left-width:1px;border-left-style:solid" class="gmail_quote">
If called twice, or more, the request will send an event to<br>
desktop-shell, so it can display a notification.<br>
</blockquote>
<br></div>
This is not controlled by a count, but by whether a window is already visible or already in the notification state. Clients should be able to send a lot of these in a row. They cannot reliably test if they are invisible and send the request only then, as there is a race condition.<br>
<br></blockquote><div><br></div></div><div>Yes, talking about it in terms of a count is a bad plan.<br></div><div><div> </div><blockquote style="margin:0px 0px 0px 0.8ex;padding-left:1ex;border-left-color:rgb(204,204,204);border-left-width:1px;border-left-style:solid" class="gmail_quote">
I also think the term "present" is not a great idea. This should be exactly the same as "raise" or "show" or "activate" or any number of other terms, but I have never seen the word "present" used before. I would reuse an existing term. One reason is to prevent somebody else from adding a redundant api for that term, because they did not realize "present" is the thing they are looking for.<br>
</blockquote><div><br></div></div><div>We also discussed the name "attention". The reason why we didn't go with "raise" or "show" is that it implies a specific action on the part of the compositor, namely showing the user the window. The term "activate" is used for something else in xdg_shell so that one's out too.<span class="HOEnZb"><font color="#888888"><br>
<br></font></span></div><span class="HOEnZb"><font color="#888888"><div>--Jason Ekstrand<br></div><div><br></div></font></span></div></div></div>
<br>_______________________________________________<br>
wayland-devel mailing list<br>
<a href="mailto:wayland-devel@lists.freedesktop.org">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></blockquote></div><br><br clear="all"><br>-- <br><div dir="ltr"><font>Regards,<br>
<br>
<i><b>Manuel BACHMANN</b><br>
Tizen Project<br>
VANNES-FR</i><br>
</font></div>
</div>