wm-spec 1.9f

[Havoc Pennington <hp redhat com>]

Hi,

Julian kindly made some revisions to the spec based on discussion
here. I've added them to the "official draft."

Appended is his message, and the diff.

Havoc

Message from Julian:

I've collated all the traffic on the list, and come up with a new 1.9f version
of the spec. Hopefully by the time this gets posted Havoc will have it on
www.freedesktop.org. I've tried to make changes where there was a clear
direction. In the case of uncertainly or the lack of a definitely better
solution I've tried to follow the principle of least change, and clarity.


Remaining comments:
_NET_MOVE_RESIZE still has a PDW comment - "what are the click co-cordinates
relative to ?" This needs to be answered. Implementers ?

The type of string properties is undefined (e.g. _NET_DESKTOP_NAMES), but the
format of other types is given (e.g. _NET_NUMBER_OF_DESKTOPS, CARDINAL/32). Is
it enough to mention in the text that it's in UTF8 encoding ? I would have
changed this, but am not familiar with X types.



Changes:
Added WM_VISIBLE_NAME STRING. Seems reasonable, and no one disagreed.

Removed second PDW comment from _NET_MOVE_RESIZE - rationale - the WM should be
told explicitly what the direction is, so that it does not have to make
assumptions about the client toolkit.

#1 Workspace addition / removal: Added / clarified using approach 2 - the
simpler. No one seemed to like approach 1. Made *format = 32* for consistency.

 #2 _NET_WM_MOVERESIZE   Could be changed for consistency from 16 to 32
	- and was !

> #3 _NET_PROPERTIES Can be dropped -
	- and was !

> #4 _NET_WM_WINDOW_TYPE Could be changed for simplicity.
	- well there was no clear mandate for this. This should follow X
convention (about which I have no idea), and break this only for performance
*if proven necessary*. So I followed the principle of least surprise, and left
it.

> #5 _NET_WM_STATE
2 issues here:

1) Change to bitfield. Havn't changed it. See 4)

2) StaysOnTop. The most controversial point. I think that lots of good points
have been raised in discussion, but no clear conclusions reached. On thinking
about this I realised that this is (would be) the only point in the spec where
clients would be allowed to dictate stacking order in a physical (On Top)
rather than logical (TYPE_DIALOG) way.

It's a big topic which the *spec* does not currently address. And, as I think
there's enough in the spec for it to be worth putting out as 1.0 I'd like to
keep it that way until after 1.0.

So I have not changed the spec in this area.

Surely GNOME and KDE can implement a specific, non spec breaking extension for
this (as you will do for other features e.g. dock swallowing).

It's clear from the debate that we need to gather a common understanding of
terms such as layers, and their effect on standard X window raising calls
before a spec covering physical stacking aspects will be ready.

We also need a common notion of what a client is allowed to do. Whilst I agree
that many issues should be handled by the WM, there are cases where it may be
more natural from the human point of view to appear to configure the
application being worked on rather than the WM. In this case IMHO there is a
good argument for letting a client app configure WM policy (mandated by the
user). A WM - Policy configuration spec anyone ?


There we go. I hope this is nearly there now. I think so. Pls read, and give
feedback. I hope that all the people who have contributed are still lurking,
and will read it.

Julian



Diff:

Index: wm-spec.sgml
===================================================================
RCS file: /home/freedesktop/wm-spec/wm-spec.sgml,v
retrieving revision 1.2
retrieving revision 1.3
diff -u -r1.2 -r1.3
--- wm-spec.sgml	2000/04/23 17:27:00	1.2
+++ wm-spec.sgml	2000/07/06 05:39:54	1.3
@@ -8,6 +8,12 @@
 <sect1>
 	<title>Introduction</title>
 	<sect2>
+		<title>Version</title>
+		<para>
+This spec is version 1.9f.
+		</para>
+	</sect2>
+	<sect2>
 		<title>What is this spec?</title>
 		<para>
 This spec defines interactions between window managers, applications and the utilities that form part of a desktop environment.  It builds on the ICCCM, which defines wm/client interactions at a lower level.  It was born out of a need to replace the original Gnome WM specification, although this specification has been designed to be independent of any one desktop environment.
@@ -28,6 +34,26 @@
 		</para>
 	</sect2>
 	<sect2>
+		<title>Changes since 1.9e</title>
+		<itemizedlist>
+			<listitem><para>
+Added _NET_WM_VISIBLE_NAME_STRING
+			</para></listitem>
+			<listitem><para>
+Removed ambiguity from _NET_NUMBER_OF_DESKTOPS and  _NET_DESKTOP_NAMES in combination.
+			</para></listitem>
+			<listitem><para>
+Set _NET_WM_MOVERESIZE format to 32 for consistency.
+			</para></listitem>
+			<listitem><para>
+Removed _NET_PROPERTIES.
+			</para></listitem>
+			<listitem><para>
+Removed comment from _NET_WM_MOVERESIZE.
+			</para></listitem>
+		</itemizedlist>
+	</sect2>		
+	<sect2>
 		<title>Changes since 1.9d</title>
 		<itemizedlist>
 			<listitem><para>
@@ -159,16 +185,21 @@
 number of virtual desktops.  
 	</para>
 	<para>
-A Pager can insert or delete a certain desktop by sending a
-_NET_{INSERT/DELETE}_DESKTOP client message to the root window.  
+A Pager can request change in the desktops number by sending a _NET_SET_NUMBER_OF_DESKTOPS message to the root window:
 	</para>
-<!--
-(l[0] = desktop
-to insert/delete). Insert must also work for appending one desktop.  When a
-desktop is deleted, the Window Manager SHOULD move its windows to the newly
-active desktop.  Applications SHOULD NOT perform this operation.
+	<programlisting><![CDATA[
+_NET_SET_NUMBER_OF_DESKTOPS
+  window = target app window
+  message_type = _NET_SET_NUMBER_OF_DESKTOPS
+  format = 32
+  data.l[0] = new_desktops_number
+]]></programlisting>
+	<para>
+The Window Manager is free to honor or reject this request. If request is honored _NET_NUMBER_OF_DESKTOPS MUST be set to the new number of desktops and _NET_VIRTUAL_ROOTS MUST be set to store the new number of desktop virtual root window IDs. The _NET_DESKTOP_NAMES property MAY remain unchanged.
+	</para>
+	<para> 
+If the number of desktops is shrinking and _NET_CURRENT_DESKTOP is out of the new range of of available desktops, then this MUST must be set to the last available desktop from the new set. If number of desktops is shrinking then clients that are still present on desktops, that are out of the new range, MUST be moved to the very last desktop from the new set. For these _NET_WM_DESKTOP MUST be updated.
 	</para>
-	-->
 	</sect2>
 	<sect2>
 		<title>_NET_DESKTOP_GEOMETRY</title>
@@ -219,8 +250,7 @@
 ]]></programlisting>
 	<para>
 The names of all virtual desktops in UTF8 encoding. This property MAY be
-changed by a Pager or the Window Mangaer at any time.  When a desktop is added
-or removed, the Window Manager MUST update this list.
+changed by a Pager or the Window Mangaer at any time.
 	</para>
 	</sect2><sect2><title>_NET_ACTIVE_WINDOW</title>
 	<programlisting><![CDATA[
@@ -285,10 +315,10 @@
 _NET_WM_MOVERESIZE
   window = target app window
   message_type = _NET_WM_MOVERESIZE
-  format = 16
-  data.s[0] = x_root 
-  data.s[1] = y_root
-  data.s[2] = direction
+  format = 32
+  data.l[0] = x_root 
+  data.l[1] = y_root
+  data.l[2] = direction
 ]]></programlisting>
 	<para>
 	This message allows an application to initiate window movement or resizing.  This allows the application to define its own move and size "grips", whilst letting the window manager control the actual move/resize.  This means that all moves / resizes can happen in a consistent manner as defined by the WM.
@@ -307,39 +337,32 @@
 #define _NET_WM_MOVERESIZE_SIZE_LEFT         7
 #define _NET_WM_MOVERESIZE_MOVE              8   /* Movement only */
 ]]></programlisting>
-	<para>
-	[[PDW: Why do we need to indicate the direction?  The WM could guess this from the click position - some WMs (eg. sawmill) have code for doing something similar when you hold eg. Meta + click in the client area... ]]
-	</para>
 	</sect2>
 	</sect1>	
 	<sect1>
 	<title>Application Window Properties</title>
-	<sect2><title>_NET_PROPERTIES</title>
+	<sect2><title>_NET_WM_NAME</title>
 	<programlisting><![CDATA[
-_NET_PROPERTIES, ATOM[]/32
+_NET_WM_NAME
 ]]></programlisting>
 	<para>
-Enables only use of listed properties on this windows.  If this property is
-set, the Window Manager MUST only handle (XGetWindowProperty) properties
-listed here.  This property MUST be set by the Client before any other _NET
-hints can be used.  If this property is set, it MUST also include any ICCCM
-client-only (not WM_STATE) hints that are set by the client.  If WM_PROTOCOLS
-is not listed here, the Window Manager SHOULD assume that it contains exactly
-WM_DELETE_WINDOW.
-	</para>
-	<para>
-This is a performance optimization.  [[MM: I still have to do a benchmark.]]
+The Client SHOULD set this to the title of the window in UTF8 encoding.  If
+set, the Window Manager should use this in preference to WM_NAME.
 	</para>
 	</sect2>
-	<sect2><title>_NET_WM_NAME</title>
+
+	<sect2><title>_NET_WM_VISIBLE_NAME_STRING</title>
 	<programlisting><![CDATA[
-_NET_WM_NAME
+_NET_WM_VISIBLE_NAME_STRING
 ]]></programlisting>
 	<para>
-The Client SHOULD set this to the title of the window in UTF8 encoding.  If
-set, the Window Manager should use this in preference to WM_NAME.
+If the Window Manager displays a window name other than _NET_WM_NAME the Window Manager MUST set this to the title displayed in UTF8 encoding.
 	</para>
+        <para>
+Rationale: For window managers that display a title different from the _NET_WM_NAME or WM_NAME of the window (i.e. xterm <1>, xterm <2>, ... is shown, but _NET_WM_NAME / WM_NAME is still xterm for each window). This property allows taskbars / pagers to display the same title as the window manager.
+        </para>
 	</sect2>
+
 	<sect2><title>_NET_WM_DESKTOP</title>
 	<programlisting><![CDATA[
 _NET_WM_DESKTOP <desktop>, CARDINAL/32