<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Thu, Dec 1, 2016 at 12:56 AM, 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 class="">On Wed, Nov 30, 2016 at 12:04:33PM -0500, Adam Goode wrote:<br>
> Hi,<br>
><br>
> See <a href="https://bugzilla.redhat.com/show_bug.cgi?id=1349225" rel="noreferrer" target="_blank">https://bugzilla.redhat.com/<wbr>show_bug.cgi?id=1349225</a> and<br>
> <a href="https://bugzilla.gnome.org/show_bug.cgi?id=767967" rel="noreferrer" target="_blank">https://bugzilla.gnome.org/<wbr>show_bug.cgi?id=767967</a><br>
><br>
> When using Client Side Decorations, toolkits cannot bind raise or lower to<br>
> user actions. This binding is traditionally used in the "middle click<br>
> titlebar to lower" action, which no longer works with CSD on Wayland.<br>
> Additionally, when click-to-raise is disabled, a click on a CSD titlebar<br>
> will not raise the window.<br>
><br>
> I would like to add 'raise' and 'lower' to xdg-shell. These requests will<br>
> take no arguments, similarly to 'set_maximized' (which is commonly bound to<br>
> double-click titlebar).<br>
<br>
</span>A client should not be able to raise itself on demand like that. Usually<br>
when raising, what they actually wanted to do is get attention because<br>
something happened, and that is what an API is supposed to do. I think<br>
the last time this was discussed it was referred to as "present" or<br>
something. GTK+ have a private protocol for this until we have something<br>
else.<br>
<br>
Regarding 'lower', any reason why this cannot be made a compositor side<br>
modifier->middle-click kind of thing? It'd work on the whole window and<br>
it'd work on all clients without any need for any protocol. There has<br>
also been discussions about having a protocol for specifying a "window<br>
title area" kind of thing, which the compositor can handle with special<br>
care would so be needed.<br>
<br></blockquote><div><br></div><div>The compositor side modifier->middle-click does work this way in mutter today. Having support for bare clicks with special meaning in certain regions is the more subtle case. What this means today is that if you configure your compositor with no-raise-on-click (for the traditional X behavior), then windows with CSD don't get raised when decorations are clicked (unless you hold a modifier key).</div><div><br></div><div>The idea of having a special title-bar area known to the compositor seems worth pursuing, but that could be abused by clients. CSD blended the lines between client and compositor roles, and X was happy to be permissive with that situation. I'm glad Wayland is non-permissive by default, but it does make things tricky.</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
I would really like to avoid having direct ways for a client to<br>
interfere with the window stacking, and especially not ones that require<br>
round trips.<br>
<span class=""><br></span></blockquote><div><br></div><div>As an alternative, what do you think of a raise/lower protocol that required evidence of a click to trigger? The client could decide on its own which buttons did what on which region of its surface (necessary for CSD), but prove to the compositor that a click of some kind actually occurred.</div><div><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>
> Is there any objection to adding these to xdg-shell, or should I<br>
> investigate another solution?<br>
><br>
<br>
</span>xdg-shell is in a state where I don't think we should add anything that<br>
is not very crucial until we have managed to declare it stable. A thing<br>
like lower/raise, which has been discussed plenty of times and is on the<br>
more controversial side, should not delay any stabilization of<br>
xdg-shell. With that said, things can be added as separate extensions in<br>
the mean time.<br>
<br>
<br>
Jonas<br>
<br>
><br>
><br>
> Thanks,<br>
><br>
> Adam<br>
<br>
> ______________________________<wbr>_________________<br>
> wayland-devel mailing list<br>
> <a href="mailto:wayland-devel@lists.freedesktop.org">wayland-devel@lists.<wbr>freedesktop.org</a><br>
> <a href="https://lists.freedesktop.org/mailman/listinfo/wayland-devel" rel="noreferrer" target="_blank">https://lists.freedesktop.org/<wbr>mailman/listinfo/wayland-devel</a><br>
<br>
</blockquote></div><br></div></div>