<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Fri, Dec 2, 2016 at 1:29 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:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div class="m_-7235950203492781179gmail-HOEnZb"><div class="m_-7235950203492781179gmail-h5">On Thu, Dec 01, 2016 at 09:28:11AM -0500, Adam Goode wrote:<br>
> On Thu, Dec 1, 2016 at 12:56 AM, Jonas Ådahl <<a href="mailto:jadahl@gmail.com" target="_blank">jadahl@gmail.com</a>> wrote:<br>
><br>
> > 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/sh<wbr>ow_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/sho<wbr>w_bug.cgi?id=767967</a><br>
> > ><br>
> > > When using Client Side Decorations, toolkits cannot bind raise or lower<br>
> > 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<br>
> > to<br>
> > > double-click titlebar).<br>
> ><br>
> > 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>
> ><br>
> The compositor side modifier->middle-click does work this way in mutter<br>
> today. Having support for bare clicks with special meaning in certain<br>
> regions is the more subtle case. What this means today is that if you<br>
> configure your compositor with no-raise-on-click (for the traditional X<br>
> behavior), then windows with CSD don't get raised when decorations are<br>
> clicked (unless you hold a modifier key).<br>
><br>
> The idea of having a special title-bar area known to the compositor seems<br>
> worth pursuing, but that could be abused by clients. CSD blended the lines<br>
> between client and compositor roles, and X was happy to be permissive with<br>
> that situation. I'm glad Wayland is non-permissive by default, but it does<br>
> make things tricky.<br>
<br>
</div></div>Right, and since the lines are now comparably blurry, I think it makes<br>
sense to move away from clients doing window management when we have the<br>
chance. Personally I'd vote for getting rid of the<br>
"middle-click-on-title-lowers" binding in mutter X11 SSD paths rather<br>
than adding it to GTK+.<br>
<span class="m_-7235950203492781179gmail-"><br></span></blockquote><div><br></div><div>Unfortunately, it is in GTK+ for a while now. We have duplication between Mutter and GTK+, CSD required GTK+ to directly implement these features. Example: <a href="https://github.com/GNOME/gtk/blob/master/gtk/gtkwindow.c#L1372" target="_blank">https://github.com/<wbr>GNOME/gtk/blob/master/gtk/<wbr>gtkwindow.c#L1372</a></div><div><br></div><div>This duplication is unfortunate. Hopefully it could be resolved someday.</div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span class="m_-7235950203492781179gmail-">
><br>
> 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>
> ><br>
> ><br>
> As an alternative, what do you think of a raise/lower protocol that<br>
> required evidence of a click to trigger? The client could decide on its own<br>
> which buttons did what on which region of its surface (necessary for CSD),<br>
> but prove to the compositor that a click of some kind actually occurred.<br>
><br>
<br>
</span>There is still no reason why a client needs to have the ability to raise<br>
itself when it can communicate what it actually wanted. IIRC the<br>
"present" proposal used input event serials (i.e. allowed the compositor<br>
to match against a click/touch/...) at its discretion.<br>
<span class="m_-7235950203492781179gmail-HOEnZb"><font color="#888888"><br>
<br></font></span></blockquote><div><br></div><div>I will have to look at the "present" proposal. Thanks for your comments.</div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span class="m_-7235950203492781179gmail-HOEnZb"><font color="#888888">
Jonas<br>
</font></span><div class="m_-7235950203492781179gmail-HOEnZb"><div class="m_-7235950203492781179gmail-h5"><br>
><br>
><br>
> > ><br>
> > > Is there any objection to adding these to xdg-shell, or should I<br>
> > > investigate another solution?<br>
> > ><br>
> ><br>
> > 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" target="_blank">wayland-devel@lists.freedeskto<wbr>p.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>
> ><br>
</div></div></blockquote></div><br></div></div>