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

[Jonas Ådahl]

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+.

> 
> 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.


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
> >
> >