[gnome-devel-docs] Mention that in-place progress indicators are preferred to modal progress dialogs windows.

[Calum Benson <calum src gnome org>]

commit 8d44cb60439158269ebb51de2ead123dc21e6930
Author: Mattthew Paul Thomas <mpt postinbox com>
Date:   Tue Mar 2 15:24:41 2010 +0000

    Mention that in-place progress indicators are preferred to
    modal progress dialogs windows.
    
    Replace guidance about progress windows having same title as
    their primary text, which lead to unnecessary redundancy. Advice
    is now that progress window title should summarize the overall
    operation.

 hig/C/hig-book.xml        |    8 ++++----
 hig/C/hig-ch-whatsnew.xml |   11 +++++++----
 hig/C/hig-ch-windows.xml  |   18 ++++++++----------
 hig/ChangeLog             |   16 ++++++++++++++++
 4 files changed, 35 insertions(+), 18 deletions(-)
---
diff --git a/hig/C/hig-book.xml b/hig/C/hig-book.xml
index 87ea701..d879280 100644
--- a/hig/C/hig-book.xml
+++ b/hig/C/hig-book.xml
@@ -23,11 +23,11 @@
 <bookinfo>
     <author role="maintainer"><firstname>The GNOME Usability Project</firstname></author>
 <copyright>
-<year>2002-2008</year>
+<year>2002-2010</year>
 <holder>Calum Benson, Adam Elman, Seth Nickell, colin z robertson</holder>
 </copyright>
-<pubdate>2008-09-25</pubdate>
-<edition>2.2</edition>
+<pubdate>2010-03-02</pubdate>
+<edition>2.2.1</edition>
 
 <abstract role="description">
 <para>This document tells you how to create applications that look right, behave
@@ -60,7 +60,7 @@ the GNOME interface are covered.</para>
   </para>
 </legalnotice>
 
-<title>GNOME Human Interface Guidelines 2.2</title>
+<title>GNOME Human Interface Guidelines 2.2.1</title>
 
 </bookinfo>
 
diff --git a/hig/C/hig-ch-whatsnew.xml b/hig/C/hig-ch-whatsnew.xml
index d0c2498..9c502ec 100644
--- a/hig/C/hig-ch-whatsnew.xml
+++ b/hig/C/hig-ch-whatsnew.xml
@@ -4,12 +4,15 @@
   <preface id="whatsnew">
     <title>What's new?</title>
     <para>This section highlights recent changes to the HIG that may affect your application.</para>
-     <para>The following changes were made in HIG v2.2:</para>
+     <para>The following changes were made in HIG v2.2.1:</para>
     <itemizedlist>
-	<listitem><para>Mention deprecation of low contrast icons in <xref linkend="icons-design-accessible"/>
+	<listitem><para>Mention in <xref linkend="windows-progress"/> that in-place progress 
+	indicators are preferred to modal progress dialogs windows.
 		</para></listitem>
     	<listitem><para>
-	    	Updated illustrations throughout.
+	    	Replace guidance in <xref linkend="windows-progress"/> about progress windows having 
+		same title as their primary text, which lead to unnecessary redundancy. Advice is now 
+		that progress window title should summarize the overall operation.
 		</para></listitem>	
 	</itemizedlist>
 
@@ -68,7 +71,7 @@
 	    <listitem><para>
 		<xref linkend="windows-primary"/>
 		</para></listitem>
-
+	    
 	    <listitem><para>
 		<xref linkend="windows-utility"/>
 		</para></listitem>
diff --git a/hig/C/hig-ch-windows.xml b/hig/C/hig-ch-windows.xml
index 078b70e..ab47b0e 100644
--- a/hig/C/hig-ch-windows.xml
+++ b/hig/C/hig-ch-windows.xml
@@ -1720,13 +1720,11 @@ saved, in case an error occurs.  Then hide the document window immediately after
     during an operation that takes more than a few seconds. See <xref
     linkend="controls-progress-bars" /> for more details about proper use of
     progress bars.</para>
-	<para>A progress window may appear in the panel window list if it
-	is, or may be, the only window shown by an application. For example,
-	the file download progress window of a web browser may remain after
-	all the browser windows have been closed.</para>
-	<para>Otherwise, a progress window should be raised above the
-	application when the application window itself is selected from the
-	window list.</para>
+		
+    <para>A progress window should always appear as an independent window in a window list.
+	If progress of a task makes a window temporarily unusable, do not present a modal dialog-like progress window in front of it.
+	Instead, present progress somewhere in the original window, making all its other elements temporarily insensitive.
+	This helps reduce visual clutter.</para>
 
     <figure id="example-progress-figure">
       <title>An example of a progress window</title>
@@ -1749,9 +1747,9 @@ saved, in case an error occurs.  Then hide the document window immediately after
     <formalpara>
       <title>Title Format</title>
 
-      <para>Progress windows should have the same title as their primary text.
-      Unlike alerts, it is expected that progress windows will be present in
-      the window list and may be active for extended periods.</para>
+      <para>Progress windows should have a title representing the overall
+      operation: for example <guilabel>Copying Files</guilabel>, <guilabel>Installing</guilabel>, or <guilabel>Calling</guilabel>.
+      As with other window titles, do not end progress window titles with an ellipsis.</para>
     </formalpara>
 
     <formalpara>
diff --git a/hig/ChangeLog b/hig/ChangeLog
index 04abfa9..c34a5df 100644
--- a/hig/ChangeLog
+++ b/hig/ChangeLog
@@ -1,3 +1,19 @@
+2010-03-02  Calum Benson <calum benson sun com>
+
+	* hig-book.xml
+	* hig-ch-whatsnew.xml
+	* hig-ch-windows.xml
+
+	Mention that in-place progress indicators are preferred to 
+	modal progress dialogs windows.
+
+	Replace guidance about progress windows having same title as 
+	their primary text, which lead to unnecessary redundancy. Advice 
+	is now that progress window title should summarize the overall 
+	operation.
+
+	Based on patch from Matthew Paul Thomas <mpt postinbox com>
+
 2009-07-23  Bryan Clark <clarkbw gnome org>
 
 	Spelling nits, as pointed out by