GladePyC 1.6

GladePyC is 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 doesnt 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 wont debate here), but for python the code generation option was not enough developped since GLC (advertised on Glades 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+, libglades XML and gtk.pys) which I find is a waste of memory for things we dont 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 doesnt 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 its not a pain to install it, but its always better if you dont 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)