Add more window manager hints

This allows the client to communicate window size increments to the compositor, and allows the compositor to inform a client that a surface has been minimized. It also allows for a client to request that attention be brought to a surface.

stable/xdg-shell/xdg-shell.xml

@@ -576,7 +576,7 @@
 
   </interface>
 
-  <interface name="xdg_toplevel" version="3">
+  <interface name="xdg_toplevel" version="4">
     <description summary="toplevel surface">
       This interface defines an xdg_surface role which allows a surface to,
       among other things, set window-like properties such as maximize,
@@ -810,7+810,7 @@
       </entry>
       <entry name="tiled_left" value="5" since="2">
 	<description summary="the surface’s left edge is tiled">
 	  The window is currently in a tiled layout and the left edge is
 	  considered to be adjacent to another part of the tiling grid.
 	</description>
       </entry>
@@ -1069,7+1069,7 @@
 	a dialog to ask the user to save their data, etc.
       </description>
     </event>
+
+    <!-- Version 4 additions -->
+
+    <request name="set_size_increment" since="4">
+      <description summary="set the size increment">
+	Set the surface’s size increment.
+
+	The client can specify an increment that the width and height
+	should be a multiple of.  This allows the compositor to avoid
+	resizing the window to a size that the client cannot handle,
+	which would force the client to resize the window again.  This
+	could result in noticable glitches.
+
+	The width and height arguments are in window geometry coordinates.
+	See xdg_surface.set_window_geometry.
+
+	Values set in this way are double-buffered. They will get applied
+	on the next commit.
+
+	The compositor can use this information to allow or disallow
+	different states like maximize or fullscreen and draw accurate
+	animations.
+
+	Similarly, a tiling window manager may use this information to
+	place and resize client windows in a more effective way.
+
+	The client should not rely on the compositor to obey the
+	increment. The compositor may decide to ignore the values set
+	by the client and request a size that is not a multiple of the
+	increment.
+
+	If never set, or a value of zero in the request, means that the
+	client has no expected increment in the given dimension.
+	As a result, a client wishing to reset the increment.
+	to an unspecified state can use zero for width and height in the
+	request.
+
+	Requesting an increment that is larger than the maximum size of
+	a surface is invalid and will result in a protocol error.
+
+	The width and height must be greater than or equal to zero. Using
+	strictly negative values for width and height will result in a
+	protocol error.
+      </description>
+      <arg name="width" type="int"/>
+      <arg name="height" type="int"/>
+    </request>
   </interface>
 
   <interface name="xdg_popup" version="3">

[Jonas Ådahl]

I don't think this is a good idea. It has a very narrow use case (terminal emulators, and practically nothing else), and doesn't really provide much value, as these clients can today already be resized the way they want.

I know there was some use case mentioned about "predicting" how clients intend to resize, but this is just one attempt to predict one narrow use case, and it will not be enough for all the others. I doubt it is possible to predict this reliably with any kind of hints.