<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Mon, Dec 19, 2016 at 10:15 PM, Jonas Ådahl <span dir="ltr"><<a href="mailto:jadahl@gmail.com" target="_blank">jadahl@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span class="gmail-">On Mon, Dec 19, 2016 at 12:55:24PM -0500, Adam Goode wrote:<br>
> Compositors currently receive "move", "resize", and "show_window_menu"<br>
> requests from clients whose decorations have been interacted with.<br>
> Clients currently implement key- and mouse-binding policies to<br>
> determine which one of these requests to send to the compositor in<br>
> response to user action.<br>
><br>
> Desktop environments traditionally have let users bind a large number of<br>
> potential actions to various interactions with decorations: not just a<br>
> handful like move and resize.<br>
><br>
> This change to xdg-shell makes the protocol more generic, allowing more<br>
> surface management policy to be implemented in the compositor directly.<br>
> This centralizes more policy in compositors, reducing policy duplication<br>
> from client toolkits and allowing for more standard surface management<br>
> behavior across them.<br>
<br>
</span>Hi,<br>
<br>
I think this is an interesting proposal, but I don't agree it's the<br>
right way to do it. Especially, I don't think we should replace<br>
move/resize with it, and I think it should be a separate extension.<br>
Reasons for this ar 1) triggering a move is not limited window<br>
decorations and I don't think its reasonable to define each such area<br>
separately, 2) a client is expected to show feedback (i.e. change<br>
cursor sprite) when hovering over area that would trigger a resize, this<br>
will not be possible since a client has no idea what will happen when<br>
clicked anymore, 3) using move/resie requests are proven to work well<br>
for what they are meant to do, 4) we're in a state where any major<br>
changes will set us back considerably when it comes to getting xdg-shell<br>
in state where we can move forward with a backward compatible base.<br>
<br>
Given this, I wouldn't mind this added as an extension. Whether this<br>
extension will eventually be added into xdg-shell "proper" can be<br>
discussed at a later point when we have some experience "in the wild",<br>
but that is not where we are now. I'd happily review such an extension,<br>
but I oppose bumping xdg-shell and replacing move/resize as is proposed<br>
here.<br>
<br>
<br>
Jonas<br>
<div><div class="gmail-h5"><br></div></div></blockquote><div><br></div><div>Hi Jonas,</div><div><br></div><div>I've been looking into how to do this properly. I've reached a bit of an impasse. Specifically, I am thinking about the problems of roundtrips.</div><div><br></div><div>Currently, move, resize, and show_window_menu take a serial that the compositor remembers. In looking at weston and mutter, this is done through implicit grabs, which (appear) to save the last single-button click that happened. There is a race condition, because if the client stalls, a new implicit grab may occur and wipe out the old one before the move/resize/etc request is sent and processed. It mostly works because roundtrips are fast enough and clients rarely stall. I think the compositor would just ignore the event if the serial doesn't match the latest grab. Lost events lead to a bad experience.</div><div><br></div><div>We could increase the number of implicit grabs that compositors remember, but that would lead to more desynchronization, as client requests come in that say "that old event from a while ago was actually a move". It is way more complicated to handle than the current single-slot implicit grab that compositors use, and seems counter-waylandic to rely on all these roundtrips and introduce these race conditions.</div><div><br></div><div>My original plans were to continue this reasoning and press on with the generic "interact" request. In implementing, I would probably need to look into storing at least a few grabs, to let compositors recognize double-clicks and such. It was looking a bit sketchy already, but then I noticed that axis events don't provide serials, and it would be nice to let "interact" allow users to implement other classic bindings, such as "spin mousewheel on titlebar to shade". Looking into how axis events are delivered to clients really made me start to think if this was the correct way at all.</div><div><br></div><div>A complex way to solve the race condition would be for clients to use a decoration mask that would be committed to the server along with surface updates. Then the compositor would know at all times exactly what interactions are on what decorations. This would easily allow compositors to even bind axis events without changing the protocol to add serials. Using wl_region seemed pretty close to what I wanted, but is fundamentally rectangular and seems expensive to update. It would be difficult to use wl_region to mask out Chrome's non-rectangular tabs, for example (see <a href="https://medium.com/google-design/redesigning-chrome-desktop-769aeb5ab987">https://medium.com/google-design/redesigning-chrome-desktop-769aeb5ab987</a> for some illustrations).</div><div><br></div><div>So what should I do next? Possible options:</div><div> 1. Stop worrying about these roundtrips and lost events and other issues and press forward with "interact".</div><div> 2. Come up with a design for non-rectangular regions and design a decoration mask protocol.</div><div> 3. Something simpler I am missing.</div><div><br></div><div>I really do want to get this working one way or another, and I'm really enjoying learning Wayland. Thanks for your feedback so far!</div><div><br></div><div><br></div><div><br></div><div>Adam</div><div><br></div><div><br></div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div><div class="gmail-h5">
><br>
> Signed-off-by: Adam Goode <<a href="mailto:agoode@google.com">agoode@google.com</a>><br>
> ---<br>
> COPYING | 1 +<br>
> unstable/xdg-shell/xdg-shell-<wbr>unstable-v7.xml | 137 +++++++++++----------------<br>
> 2 files changed, 55 insertions(+), 83 deletions(-)<br>
><br>
> diff --git a/COPYING b/COPYING<br>
> index 8ab3291..73cebf9 100644<br>
> --- a/COPYING<br>
> +++ b/COPYING<br>
> @@ -6,6 +6,7 @@ Copyright © 2014 Jonas Ådahl<br>
> Copyright © 2014 Jason Ekstrand<br>
> Copyright © 2014-2015 Collabora, Ltd.<br>
> Copyright © 2015 Red Hat Inc.<br>
> +Copyright © 2016 Google Inc.<br>
><br>
> Permission is hereby granted, free of charge, to any person obtaining a<br>
> copy of this software and associated documentation files (the "Software"),<br>
> diff --git a/unstable/xdg-shell/xdg-<wbr>shell-unstable-v7.xml b/unstable/xdg-shell/xdg-<wbr>shell-unstable-v7.xml<br>
> index de5d21c..5b99eec 100644<br>
> --- a/unstable/xdg-shell/xdg-<wbr>shell-unstable-v7.xml<br>
> +++ b/unstable/xdg-shell/xdg-<wbr>shell-unstable-v7.xml<br>
> @@ -580,101 +580,72 @@<br>
> <arg name="app_id" type="string"/><br>
> </request><br>
><br>
> - <request name="show_window_menu"><br>
> - <description summary="show the window menu"><br>
> - Clients implementing client-side decorations might want to show<br>
> - a context menu when right-clicking on the decorations, giving the<br>
> - user a menu that they can use to maximize or minimize the window.<br>
> -<br>
> - This request asks the compositor to pop up such a window menu at<br>
> - the given position, relative to the local surface coordinates of<br>
> - the parent surface. There are no guarantees as to what menu items<br>
> - the window menu contains.<br>
> -<br>
> - This request must be used in response to some sort of user action<br>
> - like a button press, key press, or touch down event.<br>
> - </description><br>
> - <arg name="seat" type="object" interface="wl_seat" summary="the wl_seat of the user event"/><br>
> - <arg name="serial" type="uint" summary="the serial of the user event"/><br>
> - <arg name="x" type="int" summary="the x position to pop up the window menu at"/><br>
> - <arg name="y" type="int" summary="the y position to pop up the window menu at"/><br>
> - </request><br>
> -<br>
> - <request name="move"><br>
> - <description summary="start an interactive move"><br>
> - Start an interactive, user-driven move of the surface.<br>
> -<br>
> - This request must be used in response to some sort of user action<br>
> - like a button press, key press, or touch down event. The passed<br>
> - serial is used to determine the type of interactive move (touch,<br>
> - pointer, etc).<br>
> -<br>
> - The server may ignore move requests depending on the state of<br>
> - the surface (e.g. fullscreen or maximized), or if the passed serial<br>
> - is no longer valid.<br>
> -<br>
> - If triggered, the surface will lose the focus of the device<br>
> - (wl_pointer, wl_touch, etc) used for the move. It is up to the<br>
> - compositor to visually indicate that the move is taking place, such as<br>
> - updating a pointer cursor, during the move. There is no guarantee<br>
> - that the device focus will return when the move is completed.<br>
> - </description><br>
> - <arg name="seat" type="object" interface="wl_seat" summary="the wl_seat of the user event"/><br>
> - <arg name="serial" type="uint" summary="the serial of the user event"/><br>
> - </request><br>
> -<br>
> - <enum name="resize_edge"><br>
> - <description summary="edge values for resizing"><br>
> - These values are used to indicate which edge of a surface<br>
> - is being dragged in a resize operation.<br>
> + <enum name="decoration_part"><br>
> + <description summary="decoration values for interacting"><br>
> + These values are used to indicate which part of a surface<br>
> + is being interacted with in an interact_with_decoration operation.<br>
> </description><br>
> <entry name="none" value="0"/><br>
> - <entry name="top" value="1"/><br>
> - <entry name="bottom" value="2"/><br>
> - <entry name="left" value="4"/><br>
> - <entry name="top_left" value="5"/><br>
> - <entry name="bottom_left" value="6"/><br>
> - <entry name="right" value="8"/><br>
> - <entry name="top_right" value="9"/><br>
> - <entry name="bottom_right" value="10"/><br>
> + <entry name="edge_top" value="1"/><br>
> + <entry name="edge_bottom" value="2"/><br>
> + <entry name="edge_left" value="4"/><br>
> + <entry name="edge_top_left" value="5"/><br>
> + <entry name="edge_bottom_left" value="6"/><br>
> + <entry name="edge_right" value="8"/><br>
> + <entry name="edge_top_right" value="9"/><br>
> + <entry name="edge_bottom_right" value="10"/><br>
> + <entry name="titlebar" value="17"/><br>
> </enum><br>
><br>
> - <request name="resize"><br>
> - <description summary="start an interactive resize"><br>
> - Start a user-driven, interactive resize of the surface.<br>
> + <request name="interact_with_<wbr>decoration"><br>
> + <description summary="respond to a client-side decoration interaction"><br>
> + Start a user-driven interaction on a client-side<br>
> + decoration. Clients should send this when a user interacts<br>
> + with the bare titlebar or edge of a client-side decoration.<br>
><br>
> This request must be used in response to some sort of user action<br>
> like a button press, key press, or touch down event. The passed<br>
> - serial is used to determine the type of interactive resize (touch,<br>
> + serial is used to determine the type of interactive action (touch,<br>
> pointer, etc).<br>
><br>
> - The server may ignore resize requests depending on the state of<br>
> - the surface (e.g. fullscreen or maximized).<br>
> -<br>
> - If triggered, the client will receive configure events with the<br>
> - "resize" state enum value and the expected sizes. See the "resize"<br>
> - enum value for more details about what is required. The client<br>
> - must also acknowledge configure events using "ack_configure". After<br>
> - the resize is completed, the client will receive another "configure"<br>
> - event without the resize state.<br>
> -<br>
> - If triggered, the surface also will lose the focus of the device<br>
> - (wl_pointer, wl_touch, etc) used for the resize. It is up to the<br>
> - compositor to visually indicate that the resize is taking place,<br>
> - such as updating a pointer cursor, during the resize. There is no<br>
> - guarantee that the device focus will return when the resize is<br>
> - completed.<br>
> -<br>
> - The edges parameter specifies how the surface should be resized,<br>
> - and is one of the values of the resize_edge enum. The compositor<br>
> - may use this information to update the surface position for<br>
> - example when dragging the top left corner. The compositor may also<br>
> - use this information to adapt its behavior, e.g. choose an<br>
> - appropriate cursor image.<br>
> + Compositors will react to this request in different ways<br>
> + depending on their own policy, but it is likely that drag<br>
> + interactions on a titlebar will result in a surface move and<br>
> + drag interactions on edges will result in a surface<br>
> + resize. Other actions are possible, depending on the<br>
> + compositor, but may include raise, lower, maximize, minimize,<br>
> + shade, or show a menu.<br>
> +<br>
> + The server may ignore grab_decoration requests depending on<br>
> + the state of the surface (e.g. fullscreen or maximized), or if<br>
> + the passed serial is no longer valid.<br>
> +<br>
> + Depending on the nature of the interaction, the client may<br>
> + receive configure events with the "resize" state enum value<br>
> + and the expected sizes. See the "resize" enum value for more<br>
> + details about what is required. The client must also<br>
> + acknowledge configure events using "ack_configure". After the<br>
> + resize is completed, the client will receive another<br>
> + "configure" event without the resize state.<br>
> +<br>
> + During some interactions, the surface will lose the focus of<br>
> + the device (wl_pointer, wl_touch, etc) used for the<br>
> + interaction. It is up to the compositor to visually indicate<br>
> + that the interaction is taking place, such as updating a<br>
> + pointer cursor. There is no guarantee that the device focus<br>
> + will return when the interaction is completed.<br>
> +<br>
> + The "decoration_part" parameter specifies what part of the client-side<br>
> + decoration has been interacted with, and is one of the values<br>
> + of the decoration_part enum. The compositor may use this<br>
> + information to update the surface position, for example when<br>
> + dragging the top left corner. The compositor may also use this<br>
> + information to adapt its behavior, e.g. choose an appropriate<br>
> + cursor image.<br>
> </description><br>
> <arg name="seat" type="object" interface="wl_seat" summary="the wl_seat of the user event"/><br>
> <arg name="serial" type="uint" summary="the serial of the user event"/><br>
> - <arg name="edges" type="uint" summary="which edge or corner is being dragged"/><br>
> + <arg name="decoration_part" type="uint" summary="which part of the decoration is being interacted with"/><br>
> </request><br>
><br>
> <enum name="state"><br>
> --<br>
> 2.8.0.rc3.226.g39d4020<br>
><br>
</div></div>> ______________________________<wbr>_________________<br>
> wayland-devel mailing list<br>
> <a href="mailto:wayland-devel@lists.freedesktop.org">wayland-devel@lists.<wbr>freedesktop.org</a><br>
> <a href="https://lists.freedesktop.org/mailman/listinfo/wayland-devel" rel="noreferrer" target="_blank">https://lists.freedesktop.org/<wbr>mailman/listinfo/wayland-devel</a><br>
</blockquote></div><br></div></div>