third_party: Update to version 7 of remote_shell_protocol

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

 <?xml version="1.0" encoding="UTF-8"?>
 <protocol name="remote_shell_unstable_v1">
 
   <copyright>
     Copyright 2016 The Chromium Authors.
 
     Permission is hereby granted, free of charge, to any person obtaining a
     copy of this software and associated documentation files (the "Software"),
     to deal in the Software without restriction, including without limitation
     the rights to use, copy, modify, merge, publish, distribute, sublicense,
@@ skipping 20 matching lines @@
     Warning! The protocol described in this file is experimental and backward
     incompatible changes may be made. Backward compatible changes may be added
     together with the corresponding interface version bump. Backward
     incompatible changes are done by bumping the version number in the protocol
     and interface names and resetting the interface version. Once the protocol
     is to be declared stable, the 'z' prefix and the version number in the
     protocol and interface names are removed and the interface version number is
     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
       and made fullscreen by the user.
     </description>
 
     <enum name="container">
       <description summary="containers for remote surfaces">
         Determine how a remote surface should be stacked relative to other
         shell surfaces.
       </description>
       <entry name="default" value="1" summary="default container"/>
       <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"
        summary="invalid notification id"/>
     </enum>
 
     <request name="destroy" type="destructor">
       <description summary="destroy remote_shell">
         Destroy this remote_shell object.
 
@@ skipping 36 matching lines @@
         Notifies client that the activated surface changed.
       </description>
       <arg name="gained_active" type="object" interface="wl_surface" allow-null="true"/>
       <arg name="lost_active" type="object" interface="wl_surface" allow-null="true"/>
     </event>
 
     <!-- Version 6 additions -->
 
     <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"/>
       <arg name="notification_id" type="string" />
     </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
       and allows for remotely managed windows.
 
       It provides requests to treat surfaces like windows, allowing to set
       properties like app id and geometry.
 
       The client must call wl_surface.commit on the corresponding wl_surface
       for the remote_surface state to take effect.
@@ skipping 269 matching lines @@
     </request>
 
     <request name="set_top_inset" since="5">
       <description summary="set top inset for surface">
         Set distance from the top of the surface to the contents.
 
         This distance typically represents the size of the window caption.
       </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 -->
 
   <interface name="zwp_notification_surface_v1" version="6">
     <description summary="A notification window">
       An interface that may be implemented by a wl_surface to host
       notification contents.
     </description>
 
     <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>
 
 </protocol>