<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Mon, Aug 18, 2014 at 12:55 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:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div class=""><br>
<br>
On 08/18/2014 04:35 AM, Pekka Paalanen wrote:<br>
<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
Obviously a stable first version of xdg_shell would be great to see in<br>
1.6, but we shall see if we can beat it into shape in time. When I<br>
reviewed the XML spec not long ago, it was close but not ready in my<br>
opinion.<br>
<br>
When xdg_shell does stabilize, we will move xdg_shell.xml into Wayland<br>
repository and it will be installed,<br>
</blockquote>
<br></div>
I know I am being a pain in the ass about this, but I don't think xdg_shell can be considered stabilized until there is an active request the client *must* do to raise a surface in response to a mouse click. If the current api is "stable" then in the future a request is going to have to be added to disable automatic raise. This will result in three apis to the default shell (wl_shell, xdg_shell with auto-raise, and xdg_shell without auto-raise), as well as adding a request that is obviously a back-compatibility hack and that all toolkits will just have to do immediately after creating each xdg_shell.<br>

</blockquote><div><br></div><div>I will be completely honest here. I don't give a shit about apps controlling raise-on-click behavior. This is not a problem I care to solve. WM policy dictates whether the window should raise on click, much like it always has under X11. Nothing in the xdg-shell protocol says that when clicking on a surface, it is raised above other surfaces.<br>
<br></div><div>That said, it is entirely possible to add a future request which can disable the WM "raise on click" behavior in the future, going to an explicit raise mode if you want, for the two clients that will use such a feature. It will not be three separate APIs, it will be an additional mode to the existing API. It will not be a big burden on my part to implement in the compositor. I do not want to burden the rest of the apps that do not care. I am not sure how this interacts with focus-follows-mouse and other sorts of stacking order, but a compositor can just pick a sane policy and live with it, I guess.<br>
</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div class=""><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">

Should we make libinput the default for 1.6, so that in 1.7 we can<br>
remove the old input code, or is libinput API still too much in flux?<br>
</blockquote>
<br></div>
Changes in the libinput api don't sound like they would be a problem, because both weston and libinput are updated at the same time. I suppose if somebody writes another compositor they may be bothered by libinput changing but that is already true.<div class="">
<div class="h5"><br>
______________________________<u></u>_________________<br>
wayland-devel mailing list<br>
<a href="mailto:wayland-devel@lists.freedesktop.org" target="_blank">wayland-devel@lists.<u></u>freedesktop.org</a><br>
<a href="http://lists.freedesktop.org/mailman/listinfo/wayland-devel" target="_blank">http://lists.freedesktop.org/<u></u>mailman/listinfo/wayland-devel</a><br>
</div></div></blockquote></div><br><br clear="all"><br>-- <br>  Jasper<br>
</div></div>