gladepyc

Purpose:

A Python code generator tool, from Glade' XML save file, to the low-level part of "PyGtk", the Python - Gtk+ binding. Glade is a GUI builder for the Gtk+ GUI toolkit. PyGtk is the gateway between Python and Gtk+.

Why:

Those who know surely have already made the remark: "But why on earth doesn't he use libglade ?"... Here is what I think of it:

• There is roughly two approaches to working with Python and Glade: a run-time one (libglade) where UI descriptions are loaded during execution, and a compile-time one where UI descriptions are statically compiled into target language source code. Both have strong and weak points (I won't debate here), but for python the code generation option was not enough developped since GLC (advertised on Glade's links page) is not object oriented. GladePyC aims to fill this little gap.
• The python binding of libglade loads the GUI using the high-level, object-oriented layer (gtk.py), not the basic layer; This means at least 3 objects per widget are present in memory (Gtk+, libglade's XML and gtk.py's) which I find is a waste of memory for things we don't need once loaded (and by adding layers it may slow down things notably).
• If you need dynamic interfaces, where multiple instances of the same window class are created, you have to reload the UI description (analyzing XML and all) because libglade doesn't know how to make a new actual widget tree from the in-memory, XML represented, UI description. Additionally you have to reload from a file: loading from a string in memory is unusable because a function is missing in the Python binding.
• It requires an additional library ! Ok it's not a pain to install it, but it's always better if you don't need it; Actually I want OpenVMS as a potential target, and it is lacking libglade.

Additionally gladepyc has some features I wanted, that are not found in libglade nor GLC:

• Object-orientedness (1): windows and widget subtrees have their building code generated as classes, so that multiple, independant instances of them can be created.
• Individual widgets are accessible by their name as attributes of instanciated objects.
• Object-orientedness (2): signal connections are made to methods of so-called "controller" objects (Java calls them "listeners"), not functions. There is support for connecting a whole set of signals at once, based on the name of callbacks, which presence is checked as methods of the controller. This allows each window (or subpart) to be managed by a separate controller without having to pass additional arguments to callbacks.
• Object-orientedness (3): data classes can be made, to serve as quick access method to data stored at runtime in widget instances. Each value is accessed as an attribute of the instanciated object, through an attribute with the same name as the corresponding widget.
• and there is a lot more: see README. I will write documentation when things have matured.

As you can see, there are some benefits to static code generation approach, which are difficult to achieve with a run-time library (though in our case it would be able to, since Python is interpreted and can dynamically define new classes and functions)

When / Status:

It seems now that all widgets of the basic set available in Glade are now handled. Gladepyc can now be considered ready for production.

A few pointless things are missing:

• get/set methods are missing for a few widgets, but they would probably be useless: Label, Tree, CTree, Scrollbar
• handle AccelLabel as Label; Don't know what's the difference after all, and it seems mixed up in Glade too.
• Image widget lacks everything

Some documentation has been put in the README file, including usage, build and install instructions. I provide a tutorial and a single example (a Python console).

Coming:

• By lack of time, I temporarily give up development. I will probably start it again when pygtk2 is stable and out. Sorry.

Future plans:

• Documentation: next to come is a reference manual. Not so long ago I realized there are so many features that I don't remember them all myself. It's about time :-)
• Extend code generation so that libglade can be used as a target just like _gtk. (and make James Henstridge happy :-)
• Use gettext to do i18n, once it's widely available in Python. For now, Gladepyc has its own message catalogs formats and loaders; At least it is portable across every platform and version.
• GNOME widgets are not implemented for now (Gtk+ has given me enough work by itself). Fearless people that want it anyway can yet implement them in a file named "gnomebuilder.py" in the way of "_gtkbuilder.py" (should be quite easy for most widgets). I designed its API so that additional widget modules can be integrated easily (once there are some !).
• When PyGtk2 is out and stable (now that GTK+ 2.0 is out), I will rewrite code generation to work with these; When it's done, the interface to generated code (classes and access methods) will not change, hence proving if necessary the interest of native code generation.

Requirements:

Gtk+ (>= 1.2.6), PyGtk (>= 0.6.8), Python (>= 1.5.2).

I'm working with Glade 0.6.2; Older (but not too much !) versions are probably fine too.

Where:

Python sources (nothing to compile) are in this tar-gzip archive: gladepyc 1.6.

PLEASE NOTE !!! Requirements changed with gladepyc 1.0 (see above).

Return to my home page.