<div dir="ltr">Hi,<br><br><div class="gmail_quote"><div dir="ltr">On Wed, Jun 1, 2016 at 5:19 AM Olivier Fourdan <<a href="mailto:ofourdan@redhat.com">ofourdan@redhat.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">When tiled, clients must obey the window geometry specified in the<br>
configure event and can choose to hide some of their decorations.<br>
<br>
Signed-off-by: Olivier Fourdan <<a href="mailto:ofourdan@redhat.com" target="_blank">ofourdan@redhat.com</a>><br>
---<br>
 unstable/xdg-shell/xdg-shell-unstable-v6.xml | 27 +++++++++++++++++++++++++++<br>
 1 file changed, 27 insertions(+)<br>
<br>
diff --git a/unstable/xdg-shell/xdg-shell-unstable-v6.xml b/unstable/xdg-shell/xdg-shell-unstable-v6.xml<br>
index ce57153..550a0e5 100644<br>
--- a/unstable/xdg-shell/xdg-shell-unstable-v6.xml<br>
+++ b/unstable/xdg-shell/xdg-shell-unstable-v6.xml<br>
@@ -343,6 +343,33 @@<br>
          active. Do not assume this means that the window actually has<br>
          keyboard or pointer focus.<br>
        </description><br>
+      <entry name="tiled_on_top" value="5" summary="the surface is tiled on its top edge"><br>
+       <description summary="the surface is tiled on its top side"><br>
+         The top side of the surface is tiled, either to another surface<br>
+         or a monitor edge. The window geometry specified in the configure<br>
+         event must be obeyed by the client.<br>
+       </description><br>
+      </entry><br>
+      <entry name="tiled_on_bottom" value="6" summary="the surface is tiled on its bottom edge"><br>
+       <description summary="the surface is tiled on its bottom side"><br>
+         The bottom side of the surface is tiled, either to another surface<br>
+         or a monitor edge. The window geometry specified in the configure<br>
+         event must be obeyed by the client.<br>
+       </description><br>
+      </entry><br>
+      <entry name="tiled_on_left" value="7" summary="the surface is tiled on its left edge"><br>
+       <description summary="the surface is tiled on its left side"><br>
+         The left side of the surface is tiled, either to another surface<br>
+         or a monitor edge. The window geometry specified in the configure<br>
+         event must be obeyed by the client.<br>
+       </description><br>
+      </entry><br>
+      <entry name="tiled_on_right" value="8" summary="the surface is tiled on its right edge"><br>
+       <description summary="the surface is tiled on its right side"><br>
+         TThe right side of the surface is tiled, either to another surface<br>
+         or a monitor edge. The window geometry specified in the configure<br>
+         event must be obeyed by the client.<br>
+       </description><br>
       </entry><br>
     </enum><br>
<br>
--<br>
2.7.4<br>
<br><br></blockquote><div><br></div><div>I've read the ticket linked in the other mail, but your use of "tiled" here is confusing to me since you (and the ticket) appear to be conflating two separate-but-unrelated meanings.  "Tiled" is a type of window layout policy which organizes windows into a tiled grid formation; this is in opposition to "stacking".</div><div><br></div><div>The ticket you linked seems to be primarily about positioning windows to take up 50% of screen geometry, (e.g., left half of screen, top half of screen, ...). This seems a lot more like a maximize state to me since it's based on screen geometry. In X11 there's NETWM hints for vertical/horizontal maximize: EFL uses these to handle partial maximizations, and in Wayland we simply use the normal MAXIMIZE window state since directionality is irrelevant. I think MAXIMIZE fully covers this case and there is no need for any further protocol to inform the client.</div><div><br></div><div>In the case of the real "tiled" state, (i.e., a tiling layout policy), I think this is something which should be a single draw state. There's no need to inform a client about its surface's relative position (e.g., any of your proposed directional tiled values) since the result is the same in every case--the client must obey configured geometry.</div><div><br></div><div>The difference from the MAXIMIZE state here is mostly conceptual: MAXIMIZE indicates to a client that a surface is taking up the entire screen's geometry on at least one axis and thus it may choose to draw UI elements differently (e.g., showing/hiding extra toolbars along the larger axis). A TILED state simply informs the client that it must obey sizing policies and draw rectangular borders. A MAXIMIZED surface cannot be tiled (since it's implicitly "tiled" by being maximized), but a tiled surface can toggle MAXIMIZE.</div></div></div>