Re: [pygtk] Patch to those who use glc.py (Python Glade Code Generator)
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
Re: [pygtk] Patch to those who use glc.py (Python Glade Code Generator)
Christian Robottom Reis writes: Why _not_ libglade, btw? The user has to have it installed. -- -russ nelson [EMAIL PROTECTED] http://russnelson.com Crynwr sells support for free software | PGPok | It's a crime, not an act 521 Pleasant Valley Rd. | +1 315 268 1925 voice | of war. For my take, see: Potsdam, NY 13676-3213 | +1 315 268 9201 FAX | http://quaker.org/crime.html ___ pygtk mailing list [EMAIL PROTECTED] http://www.daa.com.au/mailman/listinfo/pygtk
Re: [pygtk] Patch to those who use glc.py (Python Glade Code Generator)
On Mon, 22 Oct 2001, Russell Nelson wrote: I agree that a) and b) are yucky. I much prefer: c) using `make' to re-generate the code whenever you change the .glade file, and never otherwise change the code. I guess... you have to rely on the generated code being good, of course, and you can't fit it into a framework like Kiwi without hacking the code generator (since the generation is monolithic, right?) I'm not too familiar with generation, but it seems a tad unflexible to me. Why _not_ libglade, btw? Take care, -- Christian Reis, Senior Engineer, Async Open Source, Brazil. http://async.com.br/~kiko/ | [+55 16] 272 3330 | NMFL ___ pygtk mailing list [EMAIL PROTECTED] http://www.daa.com.au/mailman/listinfo/pygtk
Re: [pygtk] Patch to those who use glc.py (Python Glade Code Generator)
On Fri, 19 Oct 2001, Russell Nelson wrote: Is there that much difference between using libglade to load a .glade file versus loading a .py generated from the same .glade file? Well, you can maintain the glade file through glade throughout the lifetime of your product, versus either a) maintaining the python code that is generated (yuck) or b) re-generating the code and redoing any customization you've done (yuck). I guess you could work around b) but libglade is still cleaner IMHO. Take care, -- Christian Reis, Senior Engineer, Async Open Source, Brazil. http://async.com.br/~kiko/ | [+55 16] 272 3330 | NMFL ___ pygtk mailing list [EMAIL PROTECTED] http://www.daa.com.au/mailman/listinfo/pygtk
Re: [pygtk] Patch to those who use glc.py (Python Glade Code Generator)
On Thu, Oct 18, 2001 at 12:57:04AM -0200, Rodrigo Senra wrote: Does anybody still use glc.py ? If not, what do you use instead to generate code templates from glade (if you do) ? Just an FYI, since you asked, I am using gladepyc to generate the main part of the GUI I'm building, along with a few custom on-the-fly widgets directly from pyGTK. The gladepyc code operates mainly on the _gtk level, and builds a fairly monolithic object, but this is more than adequate for the mostly-static parts of the interface. -- A. ___ pygtk mailing list [EMAIL PROTECTED] http://www.daa.com.au/mailman/listinfo/pygtk
Re: [pygtk] Patch to those who use glc.py (Python Glade Code Generator)
Hello Rodrigo, I'm the guy who wrote gladepyc. On Thursday, 18 October 2001, you (Rodrigo Senra) wrote: ... Cool tip about gladepyc, is there a good reason for the absence of a link to this project in PyGTK Home Page ? Good idea. Don't know why, I didn't think about it before. However I just had a look on PyGTK home and links pages, and GLC does not appear there either. A long time ago I have submitted the link to Glade's author (Damon Chaplin), so that it would appear on Glade's links page, which is where I initially found GLC; Unfortunately the link still hasn't appeared. On the other hand, James is the author of both PyGTK and libglade, and the latter is being promoted vigorously (as you saw in the first answer :-). Not sure James is willing to add a link to a concurrent product ;) -- Hope this helps, Fabien. ___ pygtk mailing list [EMAIL PROTECTED] http://www.daa.com.au/mailman/listinfo/pygtk
Re: [pygtk] Patch to those who use glc.py (Python Glade Code Generator)
|Christian Robottom Reis [EMAIL PROTECTED], |on Thu, 18 Oct 2001 01:02:25 -0200 (BRST) |about Re: [pygtk] Patch to those who use glc.py (Python Glade Code Generator) On Thu, 18 Oct 2001, Rodrigo Senra wrote: Does anybody still use glc.py ? If not, what do you use instead to generate code templates from glade (if you do) ? There is the libglade alternative, which IMHO is much superior to code generation; if you must use code generation, there is the alternative of using gladepyc, which is OO. I haven't used it, since libglade rocks so much, but you can try at http://www.fcoutant.freesurf.fr/gladepyc.html As for Libglade I already had heard, but haven't tried though (I will now!) Cool tip about gladepyc, is there a good reason for the absence of a link to this project in PyGTK Home Page ? Thx Senra ___ Rodrigo Senra Computer Engineer (GPr Sistemas Ltda) [EMAIL PROTECTED] MSc Student (IC - UNICAMP) [EMAIL PROTECTED] http://www.ic.unicamp.br/~921234 (LinUxer 217.243) (ICQ 114477550) ___ pygtk mailing list [EMAIL PROTECTED] http://www.daa.com.au/mailman/listinfo/pygtk
Re: [pygtk] Patch to those who use glc.py (Python Glade Code Generator)
On Thu, 18 Oct 2001, Rodrigo Senra wrote: As for Libglade I already had heard, but haven't tried though (I will now!) Libglade is trop cool. It loads the glade file in runtime and renders the widgets for you. No more defining boxes in code, or digging through lines and lines of pack_start() etc etc to add that 1 border you wanted. It really is neat. I've been using it a lot and it makes things _much_ faster to develop. Cool tip about gladepyc, is there a good reason for the absence of a link to this project in PyGTK Home Page ? Uhm, James? (AFAICT he hasn't been updating that page very often so...) Take care, -- Christian Reis, Senior Engineer, Async Open Source, Brazil. http://async.com.br/~kiko/ | [+55 16] 272 3330 | NMFL ___ pygtk mailing list [EMAIL PROTECTED] http://www.daa.com.au/mailman/listinfo/pygtk
[pygtk] Patch to those who use glc.py (Python Glade Code Generator)
Hi, I have sent an e-mail to glc.py creator's Bill Allen with a patch that fixes notebook code generation. The same patch is included in this message. Till now I have not receive a response from him. Does anybody know a way to contact him ? Does anybody still use glc.py ? If not, what do you use instead to generate code templates from glade (if you do) ? TIA Senra ___ Rodrigo Senra Computer Engineer (GPr Sistemas Ltda) [EMAIL PROTECTED] MSc Student (IC - UNICAMP) [EMAIL PROTECTED] http://www.ic.unicamp.br/~921234 (LinUxer 217.243) (ICQ 114477550) glc-notebookName.patch Description: Binary data
Re: [pygtk] Patch to those who use glc.py (Python Glade Code Generator)
On Thu, 18 Oct 2001, Rodrigo Senra wrote: Does anybody still use glc.py ? If not, what do you use instead to generate code templates from glade (if you do) ? There is the libglade alternative, which IMHO is much superior to code generation; if you must use code generation, there is the alternative of using gladepyc, which is OO. I haven't used it, since libglade rocks so much, but you can try at http://www.fcoutant.freesurf.fr/gladepyc.html Take care, -- Christian Reis, Senior Engineer, Async Open Source, Brazil. http://async.com.br/~kiko/ | [+55 16] 272 3330 | NMFL ___ pygtk mailing list [EMAIL PROTECTED] http://www.daa.com.au/mailman/listinfo/pygtk
