GNOME.org
 

Re: Last call for EWMH 1.2

On Tuesday 01 October 2002 15:15, Matthias Clasen wrote:
> Unless somebody complains loudly (and quickly),
> I'm going to declare the current EWMH draft the final 1.2.
>

Enclosed is my patch for spelling mistakes, grammar and the like.  Note I 
removed a few British English spellings.  Not because I am pro-American 
English but simply because the text was not consistent and was more American 
than British in content.

I also have a few style comments and general spec questions.  Note I am in the 
process of implementing ewmh for the Blackbox window manager and its tools so 
some of these are derived from my attempts to implement certain features.

WM vs. Window Manager v. window manager.  Pick one, pick two but do we really 
need all three?

The docbook text could use straightening up so it is easier to edit.  Many 
paragraphs are just one long line without breaks.

net_wm_state's ADD, REMOVE, and TOGGLE are given atom names even though they 
are meant to be #defines/constants.  I got this wrong the first time I 
implemented the atom in Blackbox.

the two visible name properties.  If a client only sets WM_NAME is the window 
manager supposed to set net_wm_visible_name?  I presume the same answer 
applies to icon_name.

skip_pager and skip_taskbar state "Applications should not set this hint if 
_NET_WM_WINDOW_TYPE already conveys the exact nature of the window".  For 
someone who does not heavily use a desktop environment what window types 
imply skip_taskbar or pager?

if a window is minimized am I supposed to change net_wm_allowed_actions?
Or does this fall under "ignore requests for unmapped windows".


--- wm-spec-1.2draft.sgml	2002-10-01 18:07:37.000000000 -0700
+++ wm-spec.sgml	2002-10-01 18:07:13.000000000 -0700
@@ -55,14 +55,14 @@ to Pagers and Applications ie. all X cli
 		<para>
 Window Managers and Clients which aim to fulfill this specification MUST adhere 
 to the ICCCM on which this specification builds. If this specification 
-explicitly modifies the ICCCM Window Managers and Clients MUST fulfil these 
+explicitly modifies the ICCCM Window Managers and Clients MUST fulfill these 
 modifications.
 		</para>
 	</sect2>
 </sect1>
 <sect1>
 <title>Non-ICCCM features</title>
-<para>There is a number of window management features or behaviours which are 
+<para>There is a number of window management features or behaviors which are 
 not specified in the ICCCM, but are commonly met in modern Window Managers and Desktop Environments.</para>
 <sect2>
 <title>Additional States</title>
@@ -114,11 +114,11 @@ for handling modality.
 <para>The Window Manager may offer to arrange the managed windows on a desktop that is 
 larger than the root window. The screen functions as a viewport on this large 
 desktop. Different policies regarding the positioning of the viewport on the 
-desktop can be implemented:  The Window Manager may only allow to change the viewport 
-position in increments of the screen size (paging) or it may allow arbitrary 
-positions (scrolling).</para>
+desktop can be implemented:  The Window Manager may only allow the viewport 
+position to change in increments of the screen size (paging) or it may allow
+arbitrary positions (scrolling).</para>
 <para>To fulfill the ICCCM principle that clients should behave the same
-regardless wether a Window Manager is running or not, Window Managers which 
+regardless whether a Window Manager is running or not, Window Managers which 
 implement large desktops must interpret all client-provided geometries with 
 respect to the current viewport.</para>
 <sect3 id="largedesksimpl">
@@ -151,8 +151,8 @@ can be shown on the screen at a time.  T
 features of virtual desktop implementations.  There may be a fixed number 
 of desktops, or new ones may be created dynamically.  The size of the desktops 
 may be fixed or variable.  If the desktops are larger than the root window, 
-their viewports (see <xref linkend="largedesks">) may be independent or forced to be at the same 
-position.</para>
+their viewports (see <xref linkend="largedesks">) may be independent or forced
+to be at the same position.</para>
 <para>A Window Manager which implements virtual desktops generally offers a way for the user
 to move clients between desktops.  Clients may be allowed to occupy more than
 one desktop simultaneously.</para>
@@ -234,7 +234,7 @@ layer.
 <para>This spec tries to address the following issues:</para>
 <itemizedlist>
 <listitem><para>Allow clients to influence their initial state with respect 
-to maximization, shading, stickyness, desktop, stacking order.</para></listitem>
+to maximization, shading, stickiness, desktop, stacking order.</para></listitem>
 <listitem><para>Improve the Window Managers ability to vary window 
 decorations and maintain the stacking order by allowing clients to hint the 
 Window Manager about the type of their windows.</para></listitem>
@@ -250,13 +250,13 @@ clients and allow them to work with any 
 <listitem><para>Window-in-window MDI.</para></listitem>
 </itemizedlist>
 <para>The Window Manager is supposed to be in charge of window management 
-policy, so that there is consistent behaviour on the user's screen no matter 
+policy, so that there is consistent behavior on the user's screen no matter 
 who wrote the clients.</para>
 <para>The spec offers a lot of external control about Window Manager actions.  
 This is intended mainly to allow pagers, taskbars and similar Window Manager 
 UIs to be implemented as separate clients.  "Ordinary" clients shouldn't use 
 these except maybe in response to a direct user request (i.e. setting a 
-config option to start maximized or specifying a -desk n cmdline 
+config option to start maximized or specifying a -desk n command line 
 argument).</para>
 </sect2>
 </sect1>
@@ -307,7 +307,7 @@ This property SHOULD be set and updated 
 number of virtual desktops. 
 	</para>
 	<para>
-A Pager can request change in the desktops number by sending a _NET_NUMBER_OF_DESKTOPS message to the root window:
+A Pager can request a change in the number of desktops by sending a _NET_NUMBER_OF_DESKTOPS message to the root window:
 	</para>
 	<programlisting><![CDATA[
 _NET_NUMBER_OF_DESKTOPS
@@ -316,10 +316,10 @@ _NET_NUMBER_OF_DESKTOPS
   data.l[0] = new_number_of_desktops
 ]]></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, _NET_VIRTUAL_ROOTS MUST be set to store the new number of desktop virtual root window IDs and _NET_DESKTOP_VIEWPORT and _NET_WORKAREA must also be changed accordingly. The _NET_DESKTOP_NAMES property MAY remain unchanged.
+The Window Manager is free to honor or reject this request. If the request is honored _NET_NUMBER_OF_DESKTOPS MUST be set to the new number of desktops, _NET_VIRTUAL_ROOTS MUST be set to store the new number of desktop virtual root window IDs and _NET_DESKTOP_VIEWPORT and _NET_WORKAREA must also be changed accordingly. 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 available desktops, then this 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.
+If the number of desktops is shrinking and _NET_CURRENT_DESKTOP is out of the new range of available desktops, then this MUST be set to the last available desktop from the new set.  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>
@@ -334,7 +334,7 @@ _NET_DESKTOP_GEOMETRY width, height, CAR
 	desktop). This property SHOULD be set by the Window Manager. 
 		</para>
 		<para>
-A Pager can request a change in  the desktop geometry by sending a _NET_DESKTOP_GEOMETRY client
+A Pager can request a change in the desktop geometry by sending a _NET_DESKTOP_GEOMETRY client
 message to the root window:
 		</para>
 	<programlisting><![CDATA[
@@ -354,7 +354,7 @@ The Window Manager MAY choose to ignore 
 _NET_DESKTOP_VIEWPORT x, y, CARDINAL[][2]/32
 ]]></programlisting>
 	<para>
-Array of pairs of cardinals that define the top left corner of each desktops 
+Array of pairs of cardinals that define the top left corner of each desktop's 
 viewport.  For Window Managers that don't support large desktops, this MUST 
 always be set to (0,0).  
 	</para>	
@@ -379,7 +379,7 @@ _NET_CURRENT_DESKTOP desktop, CARDINAL/3
 	<para>
 The index of the current desktop. This is always an integer between 0 and 
 _NET_NUMBER_OF_DESKTOPS - 1. This MUST be set and updated by the Window 
-Manager  If a Pager wants to switch to another virtual desktop, it MUST send 
+Manager.  If a Pager wants to switch to another virtual desktop, it MUST send 
 a _NET_CURRENT_DESKTOP client message to the root window:
 	</para>
 	<programlisting><![CDATA[
@@ -399,10 +399,10 @@ The names of all virtual desktops. This 
 	</para>
 <para>
 Note: The number of names could be different from _NET_NUMBER_OF_DESKTOPS.
-If it is less than _NET_NUMBER_OF_DESKTOPS - then the desktops with high
+If it is less than _NET_NUMBER_OF_DESKTOPS, then the desktops with high
 numbers are unnamed. If it is larger than _NET_NUMBER_OF_DESKTOPS, then the 
 excess names outside of the _NET_NUMBER_OF_DESKTOPS are considered to be
-reserved in case number of desktops is increased.
+reserved in case the number of desktops is increased.
 </para>
 <para>
 Rationale: The name is not a necessary attribute of a virtual desktop. Thus 
@@ -435,7 +435,7 @@ _NET_WORKAREA, x, y, width, height CARDI
 ]]>
 	</programlisting>
 	<para>
-This property MUST be set by WM upon calculating the work area for 
+This property MUST be set by the WM upon calculating the work area for 
 each desktop.  Contains a geometry for each desktop.  These geometries are 
 specified relative to the viewport on each desktop and specify an area that is
 completely contained within the viewport.
@@ -513,7 +513,7 @@ _NET_DESKTOP_LAYOUT, orientation, x, y, 
   starting corner of the layout, i.e. the corner containing the first desktop.
         </para>
   <para>
-   Note: In order to interoperate with Pagers implementing an earlier
+   Note: In order to inter-operate with Pagers implementing an earlier
    draft of this document, Window Managers should accept a
   _NET_DESKTOP_LAYOUT property of length 3 and
   use _NET_WM_TOPLEFT as the starting corner in this case.
@@ -529,7 +529,7 @@ _NET_DESKTOP_LAYOUT, orientation, x, y, 
         </para>
         <para>
   When the orientation is _NET_WM_ORIENTATION_HORZ
-  the desktops are layed out in rows, with the first desktop in the 
+  the desktops are laid out in rows, with the first desktop in the 
   specified starting corner. So a layout with X=4 and Y=3 starting in 
   the _NET_WM_TOPLEFT corner looks like this:
 <programlisting>
@@ -595,7 +595,7 @@ _NET_SHOWING_DESKTOP desktop, CARDINAL/3
 	Some Window Managers have a "showing the desktop" mode in which windows
 	are hidden, and the desktop background is displayed and focused. If a
 	Window Manager supports the _NET_SHOWING_DESKTOP hint, it MUST set it
-	to a value of 1 if the Window Manager is in "showing the desktop" mode,
+	to a value of 1 when the Window Manager is in "showing the desktop" mode,
 	and a value of zero if the Window Manager is not in this mode.
         </para>
         <para>
@@ -665,9 +665,9 @@ _NET_MOVERESIZE_WINDOW
 	</para>
         <para>
 	Window Managers should treat a _NET_MOVERESIZE_WINDOW message exactly 
-	like a ConfigureRequest (in particular, adhere to the ICCCM rules about
-	synthetic ConfigureNotify events), except that they should use the
-	gravity specified in the message. 
+	like a ConfigureRequest (in particular, adhering to the ICCCM rules
+	about synthetic ConfigureNotify events), except that they should use
+	the gravity specified in the message. 
         </para>
 	<para>
 	Rationale: Using a _NET_MOVERESIZE_WINDOW message with StaticGravity
@@ -700,8 +700,8 @@ _NET_WM_MOVERESIZE
 	window and direction MUST indicate whether this is a move or resize 
 	event, and if it is a resize event, which edges of the window the size 
 	grip applies to. When sending this message in response to a key event, 
-	the direction MUST indicate wether this this is a move or resize event 
-	and the other fields are unused. 
+	the direction MUST indicate whether this this is a move or resize
+	event and the other fields are unused. 
 	</para>
 	<programlisting><![CDATA[
 #define _NET_WM_MOVERESIZE_SIZE_TOPLEFT      0
@@ -723,7 +723,7 @@ _NET_WM_MOVERESIZE
         The Window Manager can use the button field to determine the
 	events on which it terminates the operation initiated by the
         _NET_WM_MOVERESIZE message. Since there is a race condition between 
-	client sending the _NET_WM_MOVERESIZE message and the user releasing 
+	a client sending the _NET_WM_MOVERESIZE message and the user releasing 
 	the button, Window Managers are advised to offer some other means to 
 	terminate the operation, e.g. by pressing the ESC key.  
         </para>
@@ -749,7 +749,7 @@ _NET_WM_VISIBLE_NAME, UTF8_STRING
 If the Window Manager displays a window name other than _NET_WM_NAME the Window Manager MUST set this to the title displayed in UTF-8 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.
+Rationale: This property is 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) thereby allowing taskbars / pagers to display the same title as the window manager.
         </para>
 	</sect2>
 
@@ -781,8 +781,8 @@ _NET_WM_DESKTOP desktop, CARDINAL/32
 	<para>
 Cardinal to determine the desktop the window is in (or wants to be) starting
 with 0 for the first desktop.  A Client MAY choose not to set this property,
-in which case the Window Manager SHOULD place as it wishes.  0xFFFFFFFF
-indicates that the window SHOULD appear on all desktops/workspaces.  
+in which case the Window Manager SHOULD place it as it wishes.  0xFFFFFFFF
+indicates that the window SHOULD appear on all desktops.  
 	</para>
 	<para>
 The Window Manager should honor _NET_WM_DESKTOP whenever a withdrawn window
@@ -790,7 +790,7 @@ requests to be mapped.
         </para>
         <para>
 The Window Manager should remove the property whenever
-a window is withdrawn, but it should leave the property in place when it is
+a window is withdrawn but it should leave the property in place when it is
 shutting down, e.g. in response to losing ownership of the WM_Sn manager 
 selection.
 	</para>
@@ -819,21 +819,21 @@ _NET_WM_DESKTOP
 _NET_WM_WINDOW_TYPE, ATOM[]/32
 ]]></programlisting>
 	<para>
-This SHOULD be set by the Client before mapping, to a list of atoms indicating
+This SHOULD be set by the Client before mapping to a list of atoms indicating
 the functional type of the window.  This property SHOULD be used by the window
-manager in determining the decoration, stacking position and other behaviour
+manager in determining the decoration, stacking position and other behavior
 of the window.  The Client SHOULD specify window types in order of preference
-(the first being most preferable), but MUST include at least one of the basic
+(the first being most preferable) but MUST include at least one of the basic
 window type atoms from the list below.  This is to allow for extension of the
-list of types, whilst providing default behaviour for window managers that do
-not recognise the extensions.  
+list of types whilst providing default behavior for window managers that do
+not recognize the extensions.  
 	</para>
 	<para>
-Rationale:  This hint is intend to replace the MOTIF hints.  One of the
+Rationale:  This hint is intended to replace the MOTIF hints.  One of the
 objections to the MOTIF hints is that they are a purely visual description of
 the window decoration.  By describing the function of the window, the window
-manager can apply consistent decoration and behaviour to windows of the same
-type.  Possible examples of behaviour include keeping dock/panels on top or
+manager can apply consistent decoration and behavior to windows of the same
+type.  Possible examples of behavior include keeping dock/panels on top or
 allowing pinnable menus / toolbars to only be hidden when another window has
 focus (NextStep style).  
 	</para>
@@ -882,7 +882,7 @@ be taken as this type.  
 	</para>
 	<para>
 _NET_WM_WINDOW_TYPE_NORMAL indicates that this is a normal, top-level window.
-Windows with neither _NET_WM_WINDOW_TYPE nor WM_TRANSIENT_FOR are set MUST
+Windows with neither _NET_WM_WINDOW_TYPE nor WM_TRANSIENT_FOR set MUST
 be taken as this type.
 	</para>
 	</sect2>
@@ -946,7 +946,7 @@ window's position fixed on the screen, e
 	</para>
 	<para>
 _NET_WM_STATE_MAXIMIZED_{VERT,HORZ} indicates that the window is
-{vertically,horizontally} maximised.
+{vertically,horizontally} maximized.
 	</para>
 	<para>
 _NET_WM_STATE_SHADED indicates that the window is shaded.
@@ -1011,7 +1011,7 @@ client message to the root window  (wind
 _NET_WM_STATE, format 32, l[0]=&lt;the action, as listed below&gt;,
 l[1]=&lt;First property to alter&gt;, l[2]=&lt;Second property to alter&gt;).
 This message allows two properties to be changed simultaneously, specifically
-to allow both horizontal and vertical maximisation to be altered together.
+to allow both horizontal and vertical maximization to be altered together.
 l[2] MUST be set to zero if only one property is to be changed. l[0], the
 action, MUST be one of:
 	</para>
@@ -1117,10 +1117,10 @@ _NET_WM_STRUT, left, right, top, bottom,
 ]]></programlisting>
 	<para>
 This property MUST be set by the Client if the window is to reserve space at
-the edge of the screen.  The property contains a 4 cardinals specifying the
+the edge of the screen.  The property contains 4 cardinals specifying the
 width of the reserved area at each border of the screen.  
 The order of the borders is left, right, top, bottom.
-The client MAY change this property anytime, therefore the Window Manager MUST
+The client MAY change this property at any time, therefore the Window Manager MUST
 watch out for property notify events.  
 	</para>
 	<para>
@@ -1144,7 +1144,7 @@ SHOULD only set one strut.
 _NET_WM_ICON_GEOMETRY, x, y, width, height, CARDINAL[4]/32
 ]]></programlisting>
 	<para>
-This optional property MAY be set by standalone tools like a taskbar or an 
+This optional property MAY be set by stand alone tools like a taskbar or an 
 iconbox.  It specifies the geometry of a possible icon in case the window is iconified.
 	</para>
 	<para>
@@ -1165,7 +1165,7 @@ icons to an appropriate size.
 		</para>
 		<para>
 This is an array of 32bit packed CARDINAL ARGB with high byte being A, low
-byte being B.  First two cardinals are width, height.  Data is in rows, left to
+byte being B.  The first two cardinals are width, height.  Data is in rows, left to
 right and top to bottom.
 		</para>
 	</sect2>
@@ -1211,7 +1211,7 @@ _NET_WM_HANDLED_ICONS
 This protocol allows the Window Manager to determine if the Client is still
 processing X events.  This can be used by the Window Manager to determine if a
 window which fails to close after being sent WM_DELETE_WINDOW has stopped
-responding, or has stalled for some other reason, such as waiting for user
+responding or has stalled for some other reason, such as waiting for user
 confirmation.  A Client SHOULD indicate that it is willing to participate in
 this protocol by listing _NET_WM_PING in the WM_PROTOCOLS property of the
 client window.
@@ -1271,7 +1271,7 @@ in applications that want to draw the ba
 		<para>
 If the WM_TRANSIENT_FOR property is set to None or Root window, the window
 should be treated as a transient for all other windows in the same group.  It
-has been noted that this is a slight ICCCM violation, but as this behaviour is
+has been noted that this is a slight ICCCM violation, but as this behavior is
 pretty standard for many toolkits and window managers, and is extremely
 unlikely to break anything, it seems reasonable to document it as standard.
 		</para>
@@ -1291,7 +1291,7 @@ unlikely to break anything, it seems rea
 	<sect2>
 	<title>Pagers and Taskbars</title>
 	<para>
-	This specification attempts to make reasonable provisions for WM independent pagers and taskbars.  Window Managers that require / desire additional functionality beyond what can be achieved using the mechanisms set out in this specification may choose to implement their own pagers, which communicates with the Window Manager using further, WM-specific hints, or some other means.
+	This specification attempts to make reasonable provisions for WM independent pagers and taskbars.  Window Managers that require / desire additional functionality beyond what can be achieved using the mechanisms set out in this specification may choose to implement their own pagers, which communicate with the Window Manager using further, WM-specific hints, or some other means.
 	</para>
         <para>
         Pagers should decide whether to show a miniature version of a
@@ -1343,15 +1343,15 @@ document offers the following clarificat
 	</para>
 	<itemizedlist>
 		<listitem><para>
-Window managers MUST honour the win_gravity field of WM_NORMAL_HINTS
+Window managers MUST honor the win_gravity field of WM_NORMAL_HINTS
    for both MapRequest _and_ ConfigureRequest events (ICCCM Version 2.0,
 	    &sect;4.1.2.3 and &sect;4.1.5)
 		</para></listitem>
 		<listitem><para>
-Applications are free to change their win_gravity setting at any time
+Applications are free to change their win_gravity setting at any time.
 		</para>
 		<para>
-If application changes its gravity then Window manager should adjust the
+If an application changes its gravity then Window manager should adjust the
 reference point, so that client window will not move as the result.
 For example if client's gravity was NorthWestGravity and reference point
 was
@@ -1366,10 +1366,10 @@ When generating synthetic ConfigureNotif
    origin of the root window (i.e., ignoring win_gravity) (ICCCM Version 2.0, &sect;4.2.3)
 		</para></listitem>
 		<listitem><para>
-XMoveWindow(w,x,y) behaviour depends on the window gravity. Upon receiving a
-request from client application the Window Manager calculates a new reference
-point, based on the client window's own size, border width and gravity. For given client
-window dimentions (width, height) and border width (bw), the reference point will be
+XMoveWindow(w,x,y) behavior depends on the window gravity. Upon receiving a
+request from a client application the Window Manager calculates a new reference
+point, based on the client window's own size, border width and gravity.
+For any given client window dimensions (width, height) and border width (bw), the reference point will be
 placed at:
 		</para>
 	  <informaltable>
@@ -1436,7 +1436,7 @@ placed at:
 	  </informaltable>
 	<para>
 The Window manager will use the reference point as calculated above,
-until next XMoveWindow request. The Window Manager will place frame decorations
+until the next XMoveWindow request. The Window Manager will place frame decorations
 in the following position, based on the window gravity :
 		</para>
 		<para>
@@ -1504,7 +1504,7 @@ window frame's center will be placed at 
 Implementation Note for Application developers:
 		</para>
 		<para>
-When client window is resized - its reference point does not move.
+When a client window is resized - its reference point does not move.
 So for example if window has SouthEastGravity and it is resized -
 the bottom-right corner of its frame will not move but instead
 top-left corner will be adjusted by the difference in size.
@@ -1513,8 +1513,8 @@ top-left corner will be adjusted by the 
 Implementation Note for WM developers :
 		</para>
 		<para>
-when calculating reference point at the time of initial placement -
-initial window's width should be taken into consideration, as if it
+When calculating the reference point at the time of initial placement -
+the initial window's width should be taken into consideration, as if it
 was the frame for this window.
 		</para></listitem>
 	</itemizedlist>
@@ -1597,8 +1597,9 @@ int net_get_hostname (char *buf, size_t 
       </para>
       <para>
 	The window manager may choose to put some windows in different 
-	stacking position, for example to allow user to bring currently active
-	window to the top and return it back when the window looses focus.
+	stacking positions, for example to allow the user to bring currently
+	a active window to the top and return it back when the window looses
+	focus.
       </para>
     </sect2>
 	</Sect1>
@@ -1904,7 +1905,7 @@ fixed formatting of _NET_CLOSE_WINDOW me
 		<title>Changes since 1.0pre1</title>
 		<itemizedlist>
 			<listitem><para>
-Removed implementation note concerning Gnome's (potential) file manager behaviour.
+Removed implementation note concerning Gnome's (potential) file manager behavior.
 			</para></listitem>
 			<listitem><para>
 The Window Movement section of the implementation notes has been revised.
[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]