pygtk-docs r800 - in trunk/2.0: . tut

[esr svn gnome org]

Author: esr
Date: Tue Oct 21 15:12:21 2008
New Revision: 800
URL: http://svn.gnome.org/viewvc/pygtk-docs?rev=800&view=rev

Log:
Add some content to the Tips section.


Modified:
   trunk/2.0/ChangeLog
   trunk/2.0/tut/TipsForWritingPygtkApplications.xml

Modified: trunk/2.0/tut/TipsForWritingPygtkApplications.xml
==============================================================================
--- trunk/2.0/tut/TipsForWritingPygtkApplications.xml	(original)
+++ trunk/2.0/tut/TipsForWritingPygtkApplications.xml	Tue Oct 21 15:12:21 2008
@@ -11,4 +11,53 @@
 section is very short, but I hope it will get longer in future editions of
 this tutorial.</para>
 
+<!-- ===================================================================== -->
+    <sect1>
+    <title>The user should drive the interface, not the reverse</title>
+
+<para>PyGTK, like other toolkits, gives you ways of invoking widgets,
+such as the <constant>DIALOG_MODAL</constant> flag passed to dialogs,
+that require a response from the user before the rest of the
+application can continue.  In Python, as in other languages, it is
+good style to use modal interface elements as little as possible.</para>
+
+<para>Every modal interaction is a place where your application is
+forcing a particular workflow on the user. While this is sometime
+unavoidable, as a general rule it is backwards; the application should
+be adapting itself to the user's preferred workflow instead.</para>
+
+<para>A particularly common case of this, which ought to be much less so 
+is confirmation prompts. Every confirmation prompt is a place where
+you should support an undo operation instead; the GIMP, the
+application GTK was originally built for, avoids many operations that
+would otherwise requite a stop-and-check with the user by having 
+an undo command that can unwind any operation it does.</para>
+
+    </sect1>
+<!-- ===================================================================== -->
+    <sect1>
+    <title>Separate your data model from your interface</title>
+
+<para>Python's flexible, duck-typed object system lowers the cost of
+architectural options that are more difficult to exercise in more
+rigid languages (yes, we <emphasis>are</emphasis> thinking of C++).
+One of these is carefully separating your data model (the classes and
+data structures that represent whatever state your application is
+designed to manipulate) from your controller (the classes that
+implement your user interface.</para>
+
+<para>In Python, a design pattern that frequently applies is to have
+one master editor/controller class that encapsulates your user interface
+(with, possibly, small helper classes for stateful widgets) and one
+master model class that encapsulates your application state (probably
+with some members that are themselves instances of small data-representation
+classes).  The controller calls methods in the model to do all its
+data manipulation; the model delegates screen-painting and
+input-event processing to the controller.</para>
+
+<para>Narrowing the interface between model and controller makes it
+easier to avoid being locked into early decisions about either part
+by adhesions with the other one.  It also makes downstream 
+maintainance and bug diagnosis easier.</para>
+    </sect1>
   </chapter>