From a2db57517b3648f52410c6861704b5c4190416c1 Mon Sep 17 00:00:00 2001
From: =?utf8?q?Kristian=20H=C3=B8gsberg?= <krh@bitplanet.net>
Date: Sat, 18 Jun 2011 08:17:40 -0400
Subject: [PATCH] Move map functionality into shell

Initial surface.attach makes the surface visible and clients
can set the surface type using shell.set_transient etc or
other interfaces prior to that.
---
 protocol/wayland.xml | 61 ++++++++++++++++++++++++++++------------------------
 1 file changed, 33 insertions(+), 28 deletions(-)

diff --git a/protocol/wayland.xml b/protocol/wayland.xml
index 9d0a539..ad35072 100644
--- a/protocol/wayland.xml
+++ b/protocol/wayland.xml
@@ -176,6 +176,39 @@
       <arg name="id" type="new_id" interface="wl_selection"/>
     </request>
 
+    <!-- Make the surface visible as a toplevel window. -->
+    <request name="set_toplevel">
+      <arg name="surface" type="object" interface="wl_surface"/>
+    </request>
+
+    <!-- Map the surface relative to an existing surface. The x and y
+         arguments specify the locations of the upper left corner of
+         the surface relative to the upper left corner of the parent
+         surface.  The flags argument controls overflow/clipping
+         behaviour when the surface would intersect a screen edge,
+         panel or such.  And possibly whether the offset only
+         determines the initial position or if the surface is locked
+         to that relative position during moves. -->
+    <request name="set_transient">
+      <arg name="surface" type="object" interface="wl_surface"/>
+      <arg name="parent" type="object" interface="wl_surface"/>
+      <arg name="x" type="int"/>
+      <arg name="y" type="int"/>
+      <arg name="flags" type="uint"/>
+    </request>
+
+    <!-- Map the surface as a fullscreen surface.  There are a number
+         of options here: on which output? if the surface size doesn't
+         match the output size, do we scale, change resolution, or add
+         black borders? is that something the client controls?  what
+         about transient surfaces, do they float on top of the
+         fullscreen? what if there's already a fullscreen surface on
+         the output, maybe you can only go fullscreen if you're
+         active?  -->
+    <request name="set_fullscreen">
+      <arg name="surface" type="object" interface="wl_surface"/>
+    </request>
+
     <!-- The configure event asks the client to resize its surface.
          The size is a hint, in the sense that the client is free to
          ignore it if it doesn't resize, pick a smaller size (to
@@ -346,34 +379,6 @@
       <arg name="y" type="int"/>
     </request>
 
-    <!-- Make the surface visible as a toplevel window. -->
-    <request name="map_toplevel"/>
-
-    <!-- Map the surface relative to an existing surface. The x and y
-         arguments specify the locations of the upper left corner of
-         the surface relative to the upper left corner of the parent
-         surface.  The flags argument controls overflow/clipping
-         behaviour when the surface would intersect a screen edge,
-         panel or such.  And possibly whether the offset only
-         determines the initial position or if the surface is locked
-         to that relative position during moves. -->
-    <request name="map_transient">
-      <arg name="parent" type="object" interface="wl_surface"/>
-      <arg name="x" type="int"/>
-      <arg name="y" type="int"/>
-      <arg name="flags" type="uint"/>
-    </request>
-
-    <!-- Map the surface as a fullscreen surface.  There are a number
-         of options here: on which output? if the surface size doesn't
-         match the output size, do we scale, change resolution, or add
-         black borders? is that something the client controls?  what
-         about transient surfaces, do they float on top of the
-         fullscreen? what if there's already a fullscreen surface on
-         the output, maybe you can only go fullscreen if you're
-         active?  -->
-    <request name="map_fullscreen"/>
-
     <!-- After attaching a new buffer, this request is used to
          describe the regions where the new buffer is different from
          the previous buffer and needs to be repainted.  Coordinates
-- 
2.7.4