Chapter 25. Tips For Writing PyGTK Applications

Table of Contents

25.1. The user should drive the interface, not the reverse
25.2. Separate your data model from your interface
25.3. How to Separate Callback Methods From Signal Handlers
25.3.1. Overview
25.3.2. Inheritance
25.3.3. Inheritance Applied To PyGTK

This section is simply a gathering of wisdom, general style guidelines and hints to creating good PyGTK applications. Currently this section is very short, but I hope it will get longer in future editions of this tutorial.

25.1. The user should drive the interface, not the reverse

PyGTK, like other toolkits, gives you ways of invoking widgets, such as the DIALOG_MODAL 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.

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.

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.