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

[Adam Goode]

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.

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.



> >
> > 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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/wayland-devel/attachments/20161201/f8a32ebe/attachment.html>