diff options
author | Kristian Høgsberg <krh@bitplanet.net> | 2011-06-18 08:17:40 -0400 |
---|---|---|
committer | Kristian Høgsberg <krh@bitplanet.net> | 2011-06-18 08:17:40 -0400 |
commit | a2db57517b3648f52410c6861704b5c4190416c1 (patch) | |
tree | eab5a30cacb3797246f18fae28fdfcd0ddb41a02 /protocol/wayland.xml | |
parent | 98d8256b8e67a417eebc314440716e66926adf92 (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.xml | 61 |
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 |