third_party: Update to version 7 of remote_shell_protocol

third_party/wayland-protocols/unstable/remote-shell/remote-shell-unstable-v1.xml

Index: third_party/wayland-protocols/unstable/remote-shell/remote-shell-unstable-v1.xml
diff --git a/third_party/wayland-protocols/unstable/remote-shell/remote-shell-unstable-v1.xml b/third_party/wayland-protocols/unstable/remote-shell/remote-shell-unstable-v1.xml
index 77fd6eaa650043dd5f5305212c158fc86e6511d5..2fa1028951b2b1d284d5e4016a327f0c2df260e4 100644
--- a/third_party/wayland-protocols/unstable/remote-shell/remote-shell-unstable-v1.xml
+++ b/third_party/wayland-protocols/unstable/remote-shell/remote-shell-unstable-v1.xml
@@ -38,7 +38,7 @@
     reset.
   </description>
 
-  <interface name="zwp_remote_shell_v1" version="6">
+  <interface name="zwp_remote_shell_v1" version="7">
     <description summary="remote_shell">
       The global interface that allows clients to turn a wl_surface into a
       "real window" which is remotely managed but can be stacked, activated
@@ -54,6 +54,17 @@
       <entry name="overlay" value="2" summary="system modal container"/>
     </enum>
 
+    <enum name="state_type">
+      <description summary="state types for remote surfaces">
+	Defines common show states for shell surfaces.
+      </description>
+      <entry name="normal" value="1" summary="normal window state"/>
+      <entry name="minimized" value="2" summary="minimized window state"/>
+      <entry name="maximized" value="3" summary="maximized window state"/>
+      <entry name="fullscreen" value="4" summary="fullscreen window state"/>
+      <entry name="pinned" value="5" summary="pinned window state"/>

[oshima, 2016/06/28 18:36:00]

just q: is it possible to add new types in the future without causing
compatibility issue?

[reveman, 2016/06/28 19:02:19]

yes, new types can be added as long as we're not changing the old of course.

+    </enum>
+
     <enum name="error">
       <entry name="role" value="0" summary="given wl_surface has another role"/>
       <entry name="invalid_notification_id" value="1"
@@ -110,8 +121,8 @@
 
     <request name="get_notification_surface" since="6">
       <description summary="create a notification surface from a surface">
-        Creates a notification_surface for the given surface, gives it the
-        notification_surface role and associated it with a notification id.
+	Creates a notification_surface for the given surface, gives it the
+	notification_surface role and associated it with a notification id.

[hidehiko, 2016/06/28 18:44:24]

nit: s/\t/        /

[reveman, 2016/06/28 19:02:19]

the rest of the file and other interfaces use tabs so I prefer to be consistent
with that

[hidehiko, 2016/06/28 19:20:12]

Looks mixed? At least, your new "state_type_changed" uses 8 space indent?

[reveman, 2016/06/28 22:58:28]

The style of upstream interfaces is 2 space indent with 8 spaces being replaced
by a tab afaict. This file is consistent with that now.

       </description>
       <arg name="id" type="new_id" interface="zwp_notification_surface_v1"/>
       <arg name="surface" type="object" interface="wl_surface"/>
@@ -119,7 +130,7 @@
     </request>
   </interface>
 
-  <interface name="zwp_remote_surface_v1" version="6">
+  <interface name="zwp_remote_surface_v1" version="7">
     <description summary="A desktop window">
       An interface that may be implemented by a wl_surface, for
       implementations that provide a desktop-style user interface
@@ -409,6 +420,21 @@
       </description>
       <arg name="height" type="int"/>
     </request>
+
+    <!-- Version 7 additions -->
+
+    <event name="state_type_changed" since="7">
+      <description summary="surface state type changed">
+	The state_type_changed event is sent by the compositor when the surface
+	state changed.
+
+	This is an event to notify that the window state changed in compositor.
+	The state change may be triggered by a client's request, or some user
+	action directly handled by the compositor. The client may choose to
+	ignore this event.
+      </description>
+      <arg name="state_type" type="uint"/>

[hidehiko, 2016/06/28 18:44:24]

QQ: Don't we need previous state type?
Is it necessary to track the state in client, too?

[reveman, 2016/06/28 19:02:19]

I considered this but I can't think of anything we'd need it for. I'm happy to
add it if you think it's a good idea.

[hidehiko, 2016/06/28 19:20:12]

Thank you for explanation. I just wanted to clarify if it is intentional. I do
not have any concrete case neither, so I'm fine with the current design.

+    </event>
   </interface>
 
   <!-- Version 6 additions -->
@@ -421,7 +447,7 @@
 
     <request name="destroy" type="destructor">
       <description summary="Destroy the notification_surface">
-        Unmap and destroy the notification surface.
+	Unmap and destroy the notification surface.
       </description>
     </request>
   </interface>