<div dir="ltr">To echo Jonas's comments, I'm also strongly opposed to adding window stacking manipulation to the xdg-shell protocol. It's already a mess handling windows which try to raise/focus themselves in X11, this is not an issue I want to handle under Wayland.<div><br></div><div>EFL also has functionality in the toolkit for this on client-side, but it does nothing on Wayland and we discourage its use under X11.</div></div><br><div class="gmail_quote"><div dir="ltr">On Fri, Dec 2, 2016 at 11:25 AM Adam Goode <<a href="mailto:agoode@google.com">agoode@google.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr" class="gmail_msg"><div class="gmail_extra gmail_msg"><div class="gmail_quote gmail_msg">On Fri, Dec 2, 2016 at 1:29 AM, Jonas Ådahl <span dir="ltr" class="gmail_msg"><<a href="mailto:jadahl@gmail.com" class="gmail_msg" target="_blank">jadahl@gmail.com</a>></span> wrote:<br class="gmail_msg"><blockquote class="gmail_quote gmail_msg" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div class="m_2977208809889516214m_-7235950203492781179gmail-HOEnZb gmail_msg"><div class="m_2977208809889516214m_-7235950203492781179gmail-h5 gmail_msg">On Thu, Dec 01, 2016 at 09:28:11AM -0500, Adam Goode wrote:<br class="gmail_msg">
> On Thu, Dec 1, 2016 at 12:56 AM, Jonas Ådahl <<a href="mailto:jadahl@gmail.com" class="gmail_msg" target="_blank">jadahl@gmail.com</a>> wrote:<br class="gmail_msg">
><br class="gmail_msg">
> > On Wed, Nov 30, 2016 at 12:04:33PM -0500, Adam Goode wrote:<br class="gmail_msg">
> > > Hi,<br class="gmail_msg">
> > ><br class="gmail_msg">
> > > See <a href="https://bugzilla.redhat.com/show_bug.cgi?id=1349225" rel="noreferrer" class="gmail_msg" target="_blank">https://bugzilla.redhat.com/show_bug.cgi?id=1349225</a> and<br class="gmail_msg">
> > > <a href="https://bugzilla.gnome.org/show_bug.cgi?id=767967" rel="noreferrer" class="gmail_msg" target="_blank">https://bugzilla.gnome.org/show_bug.cgi?id=767967</a><br class="gmail_msg">
> > ><br class="gmail_msg">
> > > When using Client Side Decorations, toolkits cannot bind raise or lower<br class="gmail_msg">
> > to<br class="gmail_msg">
> > > user actions. This binding is traditionally used in the "middle click<br class="gmail_msg">
> > > titlebar to lower" action, which no longer works with CSD on Wayland.<br class="gmail_msg">
> > > Additionally, when click-to-raise is disabled, a click on a CSD titlebar<br class="gmail_msg">
> > > will not raise the window.<br class="gmail_msg">
> > ><br class="gmail_msg">
> > > I would like to add 'raise' and 'lower' to xdg-shell. These requests will<br class="gmail_msg">
> > > take no arguments, similarly to 'set_maximized' (which is commonly bound<br class="gmail_msg">
> > to<br class="gmail_msg">
> > > double-click titlebar).<br class="gmail_msg">
> ><br class="gmail_msg">
> > A client should not be able to raise itself on demand like that. Usually<br class="gmail_msg">
> > when raising, what they actually wanted to do is get attention because<br class="gmail_msg">
> > something happened, and that is what an API is supposed to do. I think<br class="gmail_msg">
> > the last time this was discussed it was referred to as "present" or<br class="gmail_msg">
> > something. GTK+ have a private protocol for this until we have something<br class="gmail_msg">
> > else.<br class="gmail_msg">
> ><br class="gmail_msg">
> > Regarding 'lower', any reason why this cannot be made a compositor side<br class="gmail_msg">
> > modifier->middle-click kind of thing? It'd work on the whole window and<br class="gmail_msg">
> > it'd work on all clients without any need for any protocol. There has<br class="gmail_msg">
> > also been discussions about having a protocol for specifying a "window<br class="gmail_msg">
> > title area" kind of thing, which the compositor can handle with special<br class="gmail_msg">
> > care would so be needed.<br class="gmail_msg">
> ><br class="gmail_msg">
> ><br class="gmail_msg">
> The compositor side modifier->middle-click does work this way in mutter<br class="gmail_msg">
> today. Having support for bare clicks with special meaning in certain<br class="gmail_msg">
> regions is the more subtle case. What this means today is that if you<br class="gmail_msg">
> configure your compositor with no-raise-on-click (for the traditional X<br class="gmail_msg">
> behavior), then windows with CSD don't get raised when decorations are<br class="gmail_msg">
> clicked (unless you hold a modifier key).<br class="gmail_msg">
><br class="gmail_msg">
> The idea of having a special title-bar area known to the compositor seems<br class="gmail_msg">
> worth pursuing, but that could be abused by clients. CSD blended the lines<br class="gmail_msg">
> between client and compositor roles, and X was happy to be permissive with<br class="gmail_msg">
> that situation. I'm glad Wayland is non-permissive by default, but it does<br class="gmail_msg">
> make things tricky.<br class="gmail_msg">
<br class="gmail_msg">
</div></div>Right, and since the lines are now comparably blurry, I think it makes<br class="gmail_msg">
sense to move away from clients doing window management when we have the<br class="gmail_msg">
chance. Personally I'd vote for getting rid of the<br class="gmail_msg">
"middle-click-on-title-lowers" binding in mutter X11 SSD paths rather<br class="gmail_msg">
than adding it to GTK+.<br class="gmail_msg">
<span class="m_2977208809889516214m_-7235950203492781179gmail- gmail_msg"><br class="gmail_msg"></span></blockquote><div class="gmail_msg"><br class="gmail_msg"></div></div></div></div><div dir="ltr" class="gmail_msg"><div class="gmail_extra gmail_msg"><div class="gmail_quote gmail_msg"><div class="gmail_msg">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" class="gmail_msg" target="_blank">https://github.com/GNOME/gtk/blob/master/gtk/gtkwindow.c#L1372</a></div><div class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg">This duplication is unfortunate. Hopefully it could be resolved someday.</div></div></div></div><div dir="ltr" class="gmail_msg"><div class="gmail_extra gmail_msg"><div class="gmail_quote gmail_msg"><div class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg"> </div><blockquote class="gmail_quote gmail_msg" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span class="m_2977208809889516214m_-7235950203492781179gmail- gmail_msg">
><br class="gmail_msg">
> I would really like to avoid having direct ways for a client to<br class="gmail_msg">
> > interfere with the window stacking, and especially not ones that require<br class="gmail_msg">
> > round trips.<br class="gmail_msg">
> ><br class="gmail_msg">
> ><br class="gmail_msg">
> As an alternative, what do you think of a raise/lower protocol that<br class="gmail_msg">
> required evidence of a click to trigger? The client could decide on its own<br class="gmail_msg">
> which buttons did what on which region of its surface (necessary for CSD),<br class="gmail_msg">
> but prove to the compositor that a click of some kind actually occurred.<br class="gmail_msg">
><br class="gmail_msg">
<br class="gmail_msg">
</span>There is still no reason why a client needs to have the ability to raise<br class="gmail_msg">
itself when it can communicate what it actually wanted. IIRC the<br class="gmail_msg">
"present" proposal used input event serials (i.e. allowed the compositor<br class="gmail_msg">
to match against a click/touch/...) at its discretion.<br class="gmail_msg">
<span class="m_2977208809889516214m_-7235950203492781179gmail-HOEnZb gmail_msg"><font color="#888888" class="gmail_msg"><br class="gmail_msg">
<br class="gmail_msg"></font></span></blockquote><div class="gmail_msg"><br class="gmail_msg"></div></div></div></div><div dir="ltr" class="gmail_msg"><div class="gmail_extra gmail_msg"><div class="gmail_quote gmail_msg"><div class="gmail_msg">I will have to look at the "present" proposal. Thanks for your comments.</div></div></div></div><div dir="ltr" class="gmail_msg"><div class="gmail_extra gmail_msg"><div class="gmail_quote gmail_msg"><div class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg"> </div><blockquote class="gmail_quote gmail_msg" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span class="m_2977208809889516214m_-7235950203492781179gmail-HOEnZb gmail_msg"><font color="#888888" class="gmail_msg">
Jonas<br class="gmail_msg">
</font></span><div class="m_2977208809889516214m_-7235950203492781179gmail-HOEnZb gmail_msg"><div class="m_2977208809889516214m_-7235950203492781179gmail-h5 gmail_msg"><br class="gmail_msg">
><br class="gmail_msg">
><br class="gmail_msg">
> > ><br class="gmail_msg">
> > > Is there any objection to adding these to xdg-shell, or should I<br class="gmail_msg">
> > > investigate another solution?<br class="gmail_msg">
> > ><br class="gmail_msg">
> ><br class="gmail_msg">
> > xdg-shell is in a state where I don't think we should add anything that<br class="gmail_msg">
> > is not very crucial until we have managed to declare it stable. A thing<br class="gmail_msg">
> > like lower/raise, which has been discussed plenty of times and is on the<br class="gmail_msg">
> > more controversial side, should not delay any stabilization of<br class="gmail_msg">
> > xdg-shell. With that said, things can be added as separate extensions in<br class="gmail_msg">
> > the mean time.<br class="gmail_msg">
> ><br class="gmail_msg">
> ><br class="gmail_msg">
> > Jonas<br class="gmail_msg">
> ><br class="gmail_msg">
> > ><br class="gmail_msg">
> > ><br class="gmail_msg">
> > > Thanks,<br class="gmail_msg">
> > ><br class="gmail_msg">
> > > Adam<br class="gmail_msg">
> ><br class="gmail_msg">
> > > _______________________________________________<br class="gmail_msg">
> > > wayland-devel mailing list<br class="gmail_msg">
> > > <a href="mailto:wayland-devel@lists.freedesktop.org" class="gmail_msg" target="_blank">wayland-devel@lists.freedesktop.org</a><br class="gmail_msg">
> > > <a href="https://lists.freedesktop.org/mailman/listinfo/wayland-devel" rel="noreferrer" class="gmail_msg" target="_blank">https://lists.freedesktop.org/mailman/listinfo/wayland-devel</a><br class="gmail_msg">
> ><br class="gmail_msg">
> ><br class="gmail_msg">
</div></div></blockquote></div></div></div>
_______________________________________________<br class="gmail_msg">
wayland-devel mailing list<br class="gmail_msg">
<a href="mailto:wayland-devel@lists.freedesktop.org" class="gmail_msg" target="_blank">wayland-devel@lists.freedesktop.org</a><br class="gmail_msg">
<a href="https://lists.freedesktop.org/mailman/listinfo/wayland-devel" rel="noreferrer" class="gmail_msg" target="_blank">https://lists.freedesktop.org/mailman/listinfo/wayland-devel</a><br class="gmail_msg">
</blockquote></div>