Raw PyGTK vs. Gladed PyGTK

by Jeremy Jones

I've been posting on my progress around the podcast grabber I've been building. You can find a couple of my back blogs here and here, and some preliminary source code here.

My latest work in the podgrabber saga has been to convert the GUI from using Glade and PyGTK to hand-coded PyGTK. See the blog posts above for more details. I have now converted over everything except for a simple configuration dialog. The old GUI view Python module (using Glade) weighed in at 419 lines of code. The new GUI view Python module (using hand-coded PyGTK) weighs in at 477 lines of code. This is really interesting to me because the Glade way didn't have any definitions of GUI code in it; all of that was stored in a .glade file. The new way has both the GUI definitions as well as the event handling code. I'm surprised that it's only a 58 line difference in size (or about 14% increase).

After making the switch to hand-coded PyGTK, I'm starting to wonder what the benefit was to using Glade. Maybe it provided me, an inexperienced GUI person, with some sort of a security blanket as I tromped through unfamiliar territory. I don't know. This is totally subjective and maybe a fallible comparison, but my code feels cleaner in the re-vamped raw PyGTK module than the module using Glade. It could be because I'm copying and pasting a lot of code from the old module and am refactoring it as I go. Or it could be because I feel more in control of the whole process, so I'm asserting myself to structure things better. Anyway, I thought this was an interesting comparison.

3 Comments

Pete
2006-07-14 11:08:26
Interesting comments. I may be a little old fashioned in that I also prefer to build my UI programmatically.


I think with more agile languages like Python autobuilt widget hierarchies are less of a win. As opposed to languages like C where the workflow is more like.
step 1: Prepare to do what I want
step 2: Do what I want
step 3: Cleanup what I did
I think Glade really helps out with some of those extra steps. When coding with Python I am generally just more focused on that "step 2".


I don't have much experience with all this, but one thing I suspect is that comign from Glade you make it easer to manage the issues like Accessibility and Internationalization. These are definitely tricky to remember with a programmatic UI, but I think tools like Glade provide all the right hooks for that stuff?

jmmv
2006-07-14 11:15:26
With .glade you also have the possibility to separate all your code from the interface definition. Then, using libglade, you can parse the .glade XML file at run-time and generate the GUI window on the fly.


What this means is that you can change the GUI without having to recompile your program nor touch any code; just modify the XML window definition and you are set. Of course, I have to understand that this is quite limited... and I'm not sure if it is that useful. (I haven't used this myself; just telling you what I have learned from other people ;-)


I also tend to prefer doing as much as possible by hand, but let me tell you... I used QT Designer for a while and it was a breeze to create graphical applications! At the beginning it made me do real aberrations in the design/code, but after learning the tool it can really be useful and a real coding speedup.

Alex T
2008-07-31 21:39:00
This is a rather worthwhile and rare comparison that I can easily see people getting stumped by while making design decisions.


Thanks for taking the moment to jot your experience down!