Hmm, I just realised that this message that I posted earlier (when this topic was current ;-) bounced because I forgot which email account I was subscribed to this list through and posted through the wrong addy... doh! So here is the message anyway since I think the gladepyc author has some interesting things to say on the topic:
> >Christian Robottom Reis wrote: > >>Why _not_ libglade, btw? An alternative glade to python code generator (gladepyc) is available at http://www.fcoutant.freesurf.fr/gladepyc.html . The author of gladepyc, Fabien Coutant, has some interesting things to say on this topic which may include several answers to the above question. I'll paste some of some of his points on this topic below (Fabien's full original remarks can be read at the above webpage): begin paste: ========= 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) ======== end paste. I don't know if all the above advantages of code generation over libglade will continue to be valid after the ultimate release of the new gtk and libglade stuff; but the fact remains that some developers will always have _some_ reason for not wanting to use the libglade solution, and I think it is is good for the code generation approach to be available to python developers along with the libglade approach, just as it is for C programmers for instance. Ideally each developer should be able to choose which approach they want to use to develop their own applications under the circumstances they must deal with. Libglade is _great_(!!), but some well supported code generation (ideally available by just checking the right option in glade like you can for lots of other languages), to support those who want or need to hand write interface code would be a good thing too. Stephen. -- Stephen Gava <[EMAIL PROTECTED]> _______________________________________________ pygtk mailing list [EMAIL PROTECTED] http://www.daa.com.au/mailman/listinfo/pygtk
