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

[Adam Goode]

Hi,

Version 2 of the original patch is here (wayland-protocols):
https://patchwork.freedesktop.org/series/16642/

Weston implementation (in progress):
https://patchwork.freedesktop.org/series/17007/


Comments welcome!


Adam


On Mon, Dec 12, 2016 at 9:11 AM, Adam Goode <agoode at google.com> wrote:

> Hi,
>
> I put together an initial proposal for this at https://patchwork.
> freedesktop.org/series/16642/
>
> Please take a look!
>
>
> Thanks,
>
> Adam
>
>
> On Thu, Dec 8, 2016 at 11:08 AM, Adam Goode <agoode at google.com> wrote:
>
>> 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/gtkwin
>>>> dow.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/20161219/79b7a4ea/attachment-0001.html>