Proposal to add 'raise' and 'lower' to xdg-shell in wayland-protocols

[Mike Blumenkrantz]

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.

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.

On Fri, Dec 2, 2016 at 11:25 AM Adam Goode <agoode at google.com> wrote:

> On Fri, Dec 2, 2016 at 1:29 AM, Jonas Ådahl <jadahl at gmail.com> wrote:
>
> On Thu, Dec 01, 2016 at 09:28:11AM -0500, Adam Goode wrote:
> > On Thu, Dec 1, 2016 at 12:56 AM, Jonas Ådahl <jadahl at gmail.com> wrote:
> >
> > > On Wed, Nov 30, 2016 at 12:04:33PM -0500, Adam Goode wrote:
> > > > Hi,
> > > >
> > > > See https://bugzilla.redhat.com/show_bug.cgi?id=1349225 and
> > > > https://bugzilla.gnome.org/show_bug.cgi?id=767967
> > > >
> > > > When using Client Side Decorations, toolkits cannot bind raise or
> lower
> > > to
> > > > user actions. This binding is traditionally used in the "middle click
> > > > titlebar to lower" action, which no longer works with CSD on Wayland.
> > > > Additionally, when click-to-raise is disabled, a click on a CSD
> titlebar
> > > > will not raise the window.
> > > >
> > > > I would like to add 'raise' and 'lower' to xdg-shell. These requests
> will
> > > > take no arguments, similarly to 'set_maximized' (which is commonly
> bound
> > > to
> > > > double-click titlebar).
> > >
> > > A client should not be able to raise itself on demand like that.
> Usually
> > > when raising, what they actually wanted to do is get attention because
> > > something happened, and that is what an API is supposed to do. I think
> > > the last time this was discussed it was referred to as "present" or
> > > something. GTK+ have a private protocol for this until we have
> something
> > > else.
> > >
> > > Regarding 'lower', any reason why this cannot be made a compositor side
> > > modifier->middle-click kind of thing? It'd work on the whole window and
> > > it'd work on all clients without any need for any protocol. There has
> > > also been discussions about having a protocol for specifying a "window
> > > title area" kind of thing, which the compositor can handle with special
> > > care would so be needed.
> > >
> > >
> > 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).
> >
> > 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.
>
> Right, and since the lines are now comparably blurry, I think it makes
> sense to move away from clients doing window management when we have the
> chance. Personally I'd vote for getting rid of the
> "middle-click-on-title-lowers" binding in mutter X11 SSD paths rather
> than adding it to GTK+.
>
>
> 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: https://github.com/GNOME/gtk/blob/master/gtk/gtkwindow.c#L1372
>
> This duplication is unfortunate. Hopefully it could be resolved someday.
>
>
>
> >
> > I would really like to avoid having direct ways for a client to
> > > interfere with the window stacking, and especially not ones that
> require
> > > round trips.
> > >
> > >
> > 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.
> >
>
> There is still no reason why a client needs to have the ability to raise
> itself when it can communicate what it actually wanted. IIRC the
> "present" proposal used input event serials (i.e. allowed the compositor
> to match against a click/touch/...) at its discretion.
>
>
>
> I will have to look at the "present" proposal. Thanks for your comments.
>
>
>
> Jonas
>
> >
> >
> > > >
> > > > Is there any objection to adding these to xdg-shell, or should I
> > > > investigate another solution?
> > > >
> > >
> > > xdg-shell is in a state where I don't think we should add anything that
> > > is not very crucial until we have managed to declare it stable. A thing
> > > like lower/raise, which has been discussed plenty of times and is on
> the
> > > more controversial side, should not delay any stabilization of
> > > xdg-shell. With that said, things can be added as separate extensions
> in
> > > the mean time.
> > >
> > >
> > > Jonas
> > >
> > > >
> > > >
> > > > Thanks,
> > > >
> > > > Adam
> > >
> > > > _______________________________________________
> > > > wayland-devel mailing list
> > > > wayland-devel at lists.freedesktop.org
> > > > https://lists.freedesktop.org/mailman/listinfo/wayland-devel
> > >
> > >
>
> _______________________________________________
> wayland-devel mailing list
> wayland-devel at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/wayland-devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/wayland-devel/attachments/20161205/a64d887a/attachment.html>