I’ve been reworking my podcast grabber. When I started putting a GUI frontend on it, I decided to use Glade because I lack any skill whatsoever in GUI development. (Glade is a GUI builder application which stores the structure of an application in XML. It is also a library which interprets the XML file and allows your application code to interact with the GUI you built.) After using Glade to build a usable interface with most of the functionality I wanted, I felt like I lacked the desired level of control over my GUI. It has also been a little bit of a hassle to layer objects in deeper containers than what I would have expected. For example, I have a couple of TreeViews side by side and I wanted them to be embedded in an HPaned (horizontal pane) so I could easily resize them. In order to put my TreeViews inside of an HPaned, I had to add another row to my main VBox, add an HPaned to it, cut and paste each of my TreeViews into it, and then delete the now-empty VBox row. This wasn’t a deal-breaker for me and there is probably an easier way to do it, but it was a little bit of a nuissance.
I have been reading docs and playing with building a GUI app by hand using PyGTK. In my reading, I came across the concepts of Actions, ActionGroups, and UIManagers in PyGTK (actually, they’re gtk constructs which have PyGTK wrappers). You can find some documentation around Actions and ActionGroups in this section of the PyGTK tutorial. Basically, you create an Action for different things a user might want to do such as quit, open a file, edit configuration settings. These actions may have different ways the user can accomplish them such as a button, a menu item, or a keyboard accelerator. You attach an Action to a “proxy object” such as a button or menu item.
The UIManager provides a way to create menus and toolbars using an XML description. Some documentation for the UIManager can be found here.
Actions seem a much more code-maintenance-friendly way of associating actions with objects the user is going to interact with as opposed to the alternative: create an object (such as a button), specify all the attributes of it such as label, tooltips, etc, and (with Glade) create event handlers by name and associate the event name with some function. I guess the alternative isn’t so bad, but it’s nice to see a library provide facilities to make code management a little nicer.
There appears to be a steeper learning curve to building a GUI by hand than using something like Glade, but I’m hoping that it’ll pay off in a tighter level of control as well as ease of maintenance. I’ll post back as I make headway with coding PyGTK by hand.
Sorry, I know this is not directly related to your post, but out of curiosity, what made you choose PyGTK over other toolkits like wxPython?
Kevin, great question. I don't really consider it off topic at all. To me, Tkinter is just ugly, so that didn't even enter into my consideration. The last time I did anything with wxWindows, the documentation was OK, but not really that Python-friendly and didn't have many examples of usage. PyGTK (from what I've seen) has better docs, both API and usage. From what I remember, wx felt muddled and tangled trying to get stuff done. Maybe that was my inexperience with doing GUI stuff, though. When I started building this podcast grabber, I was really only concerned with Gnome, but wanted to make it more cross platform friendly, so plain vanilla PyGTK seemed fine, although wx is possibly a better cross platform choice.
So, I guess it boils down to 1) it's really gnome friendly (wx probably is as well), 2) I've opened up the code to several projects in Ubuntu which use it, 3) the docs are great, 4) it was already installed on my laptop and widely available otherwise, 5) I'm really not having a problem figuring out how to get stuff done. After glancing again at the wx docs, I think I'll stick to PyGTK :-) They don't look any better from what I remember.
Have you tried the wxPython demo, BTW? (IIUC it's in Ubuntu universe) It's true the C++ docs are not very Python-friendly, but the wxPython demo has real, working (and often extensive) demos of pretty much every control/class in the toolkit, along with Python/wxPython interaction issues like threads, etc. You can also edit the demos in real-time (i.e. while it's running) to play with things. ;-) Also, as for examples, were you aware of the wxPython Cookbook (on http://wiki.wxpython.org)?
On the matter of GNOME support, my main platform is OS X (and I test regularly on Win), but wxGTK is basically a GTK wrapper, so it uses GTK controls for most things. We do optimize for GNOME where possible, like supporting stock buttons, offering optional GNOME print support and using the GNOME MIME type library, but I don't know if it could be called complete/extensive.
In any case, I am obviously a fan of wxPython, and I'd just like to know how we can make the wxPython experience better for those working on cross-platform (or cross-platform ready) apps. I was just curious to know if you saw the resources but they didn't meet your needs/criteria, or if you hadn't seen the resources perhaps because it wasn't immediately obvious what resources were available. Thanks for taking time out to discuss this! :-)