Create User Interfaces with Glade

GladeBase automates the conversion of Gtk+ widget hierarchies to Python object hierarchies and automatically connects Python-based signal handlers, but it still requires you to identify and implement all of the signal handlers defined in a Glade project file. For pure Gtk+ projects this is no problem because the only signal handlers are the ones you explicitly define.

However, when you use Glade to build a GNOME application, many signal handlers are defined automatically. For example, a new Gnome Application window is created with a standard menubar whose menu items all have predefined activate signal handlers. It can be tedious to browse through GNOME-based projects, manually locating predefined signal handlers and adding them to your application controllers.

As noted earlier, Glade project files are stored in an XML format (as of yet there is no DTD describing the structure of a project file, but it is easy to understand by inspection). Python 2.0 includes an XML library, layered atop James Clark's Expat library. So it's fairly easy to build a Python application that rummages through a Glade project file, identifies all of the signal handlers declared in a given widget hierarchy and generates a stubbed Controller module for that hierarchy.

GladeProjectSignals.py (see Listing 3 at ftp://ftp.linuxjournal.com/pub/lj/listings/issue87/) extracts signal-handler information from a Glade project file. The module has two main abstractions. Class WidgetTreeSignals traverses an XML DOM (document object model) tree representing a widget hierarchy and records all of the signal handler declarations it finds. Class GladeProjectSignals loads a Glade project file and builds up a dictionary of WidgetTreeSignal instances, one for each top-level widget defined in the project file.

The constructor for WidgetTreeSignals takes a DOM node as argument. It assumes this node describes a widget and expects it to contain a name node defining the widget's name. Having recorded the widget's name, WidgetTreeSignals walks the DOM tree. It checks each visited node to see if it is a signal node. If it is, WidgetTreeSignals records the value of the node's handler child, which should be the name of a signal handler. Otherwise, WidgetTreeSignals assumes the node contains child nodes and continues traversing those.

GladeProjectSignals is comparatively simple. It uses Python's xml.dom.minidom package to load a Glade project file as a DOM tree. Then it searches the tree for top-level widget nodes (a Glade design file contains other top-level nodes such as the GTK-Interface and project nodes). For every widget node found, GladeProjectSignals creates a new WidgetTreeSignals instance, which in turn lists the signal handlers defined by that widget and its descendants. Each WidgetTreeSignal instance is stored in a dictionary, self.widgets, keyed by top-level widget name.

ControllerGenerator.py (see Listing 4 at ftp://ftp.linuxjournal.com/pub/lj/listings/issue87/), when invoked with a Glade project filename and the name of a top-level widget defined in that file, prints out a stubbed Controller for that widget and its children.

Most of the module's work is done by class ControllerGenerator. This class defines a generate method that takes a Glade project filename and top-level widget name as arguments. The generate method uses an instance of GladeProjectSignals to find the handlers for the named widget. Then it creates a list of stubs for those handlers. Using a template string and Python's string formatting operators, generate produces a string containing the body of the stubbed Controller module and returns that to its caller.

Glade, libglade and gnome-python can greatly reduce the effort of building Gtk+ and GNOME applications in Python. The tools presented in this article reduce maintenance costs even further by automating the conversion of Glade widget hierarchies to Python object hierarchies, automatically connecting signal handlers defined in Controllers and generating stubbed Controllers.

Resources