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

Thu Dec 8 16:08:30 UTC 2016

On Thu, Dec 8, 2016 at 10:42 AM, Mike Blumenkrantz <
michael.blumenkrantz at gmail.com> wrote:

> Allowing clients to raise/lower has nothing to do with trust and
> everything to do with control. If clients can affect stacking, they can
> affect the compositor's window placement policy. Wayland is all about
> having the compositor be in absolute control of this to the point of
> clients having the perception of being sandboxed, hence why there is no
> method for windows to set/request/know their position on screen.
>
> I have no plans at this time to r-b any wayland-protocols addition which
> allows direct client manipulation of window stacking, regardless of how
> cleverly written it may be.
>
> Specifying CSD titlebar regions is just going to lead to even more
> complexity; if you're dead set on this, I'd suggest an extension which just
> notifies the compositor when the titlebar has been clicked; the compositor
> can then choose to take action based on its policies.
>
>
This would be equivalent to renaming the current xdg-shell 'move' request
to 'titlebar_grab' (and 'resize' to 'edge_grab'), and removing the
description of the actual move and resize semantics from the protocol
description. I believe it is essentially what Bill Spitzak initially
proposed.

If we want to have the semantics of server-side decorations (where the
compositor is completely in control of windows), but allow clients complete
control over the appearance of such decorations, then we should make that
split clear and talk of "decorations" in the protocol, not "actions".

This would allow a clear delegation of policy to the compositor without
material change to the protocol. The use of "grab" makes it clearer that
the compositor is in charge of deciding what to do (it is less specific
than "move" or "resize").

You could also fold these two requests together into just "grab", change
the "resize_edge" enum to be called "grab_region", and add a new entry for
"titlebar".

Adam

>
> On Tue, Dec 6, 2016 at 3:51 PM Adam Goode <agoode at google.com> wrote:
>
>> On Mon, Dec 5, 2016 at 11:11 AM, Mike Blumenkrantz <
>> michael.blumenkrantz at gmail.com> wrote:
>>
>> 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
>>
>>
>>
>> So I looked a bit at the present proposal from some time ago. It is not
>> exactly what I had in mind, but not too far off.
>>
>> Let me try to summarize what the state is here and possible future
>> outcomes. Please correct me if I get any details wrong.
>>
>> Here are my current assumptions/observations:
>> A1. Client-side decoration (CSD) is here to stay. At least GTK+ and
>> Chrome use this to put widgets into the titlebar area. I assume Qt and EFL
>> (and others) do this as well, but I haven't looked in detail.
>> A2. CSD is used to create non-rectangular areas within titlebars that
>> respond to user action. (Chrome tabs are not rectangular, and the titlebar
>> sits behind them.)
>> A3. Users should be able to bind 'raise' and 'lower' to mouse events in
>> window titlebars.
>> A4. Wayland developers would prefer to have all window manipulation
>> events (maximize, move, resize, raise, lower) be exclusively in control of
>> the compositor, preferably with no round trip to clients.
>> A5. Wayland developers are very concerned about clients abusing raise and
>> lower.
>>
>> One way to fulfill A4/A5 would be to do away with CSD, but A1 doesn't let
>> us. So, as a compromise, we get these requests in xdg-shell:
>> - show_window_menu
>> - move
>> - resize
>> - set_maximized
>> - set_minimized
>>
>> These requests allow the compositor to trust clients in requesting
>> certain actions. But because of A5, raise and lower are not a part of
>> xdg-shell. This is in conflict with A3.
>>
>>
>> Some quick (but not great) ways forward:
>>
>> - Eliminate A1. Unlikely to happen. But then we could switch to giving
>> full control back to the compositor and allow raise/lower to just work as
>> it used to before CSD.
>> - Eliminate A3. This is the simplest option, but the least satisfying
>> from my perspective. I'll assume we're going to keep this requirement,
>> since GNOME has supported this for a very long time.
>> - (I am not going to propose relaxing A4 or A5 here.)
>>
>>
>> Assuming a non-trivial solution, the way forward is to continue to build
>> a protocol to simulate more of non-CSD behavior in a CSD world. xdg-shell
>> covers a lot of this. It mostly comes down to how much the compositor is
>> willing to trust clients. Here is my understanding of this currently:
>>
>> examples where the compositor mostly trusts clients:
>> - set_maximized
>> - set_minimized
>> - close
>> - set_fullscreen
>> - configure
>>
>> These can be initiated by clients without any user interaction. The
>> compositor has no way to know if a user triggered these actions, nor does
>> it care. It can always apply some policy before acting.
>>
>>
>> examples where the compositor asks for some verification:
>> - show_window_menu
>> - move
>> - resize
>>
>> In these cases, the compositor requires a serial and other info to
>> enforce that a user actually clicked or touched, to avoid abuse of grabbing.
>>
>>
>> Now we are at raise and lower. By A5 above, these are sensitive requests
>> and should have scrutiny. How sensitive? If they are no more sensitive than
>> a grab, we could use the same precautions as move and resize and require
>> the compositor to supply a valid serial and other information to the
>> compositor to verify a user's intent. If this is acceptable, I can prepare
>> some proposals that include serial and seat.
>>
>>
>> If raise and lower are even more sensitive than move and resize (or if it
>> is not desired to do it this way), then clients could tell the compositor
>> the set of pixels that comprise each part of the CSD, and let the
>> compositor have full control. This would allow us to avoid round trips for
>> even move and resize, but (because of A2 above) might require a something
>> like another surface to be sent to the compositor whenever the client
>> changes in such a way that changes which pixels belong to the title bar.
>> There is probably some way to do this more cleverly, but something like a
>> bitmask would be needed.
>>
>>
>>
>> That summarizes my thoughts here. Hopefully I've captured most of the
>> issues involved. Thanks for reading this far, comments welcome.
>>
>>
>> Thanks,
>>
>> Adam
>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/wayland-devel/attachments/20161208/3144a543/attachment-0001.html>