summaryrefslogtreecommitdiff
path: root/protocol/wayland.xml
diff options
context:
space:
mode:
authorKristian Høgsberg <krh@bitplanet.net>2011-06-18 08:17:40 -0400
committerKristian Høgsberg <krh@bitplanet.net>2011-06-18 08:17:40 -0400
commita2db57517b3648f52410c6861704b5c4190416c1 (patch)
treeeab5a30cacb3797246f18fae28fdfcd0ddb41a02 /protocol/wayland.xml
parent98d8256b8e67a417eebc314440716e66926adf92 (diff)
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.
Diffstat (limited to 'protocol/wayland.xml')
-rw-r--r--protocol/wayland.xml61
1 files 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