I just finished off a small project in wxPython and I must say I am pretty impressed with the library. A couple of weeks back I had to do a small assignment (, not relating to the game or the engine I am currently working on) which required a fairly amount of GUI. The specification of the project demanded that the software be able to run on Linux, Win32 and Solaris. Solaris support however, was later dropped due to time constraints. It was a pretty small project (, considering of course I am working on the engine and the game for well over 2 years now). About a sum total of 5 days of work in the end. I was a bit hesitant to take on the work initially but changed my mind once it was decided that Python and wxPython was OK.

I’ve been meaning to take wxPython for a ride for a while now and this seemed like the perfect opportunity. If you have read my Selecting a scripting language articles (1 & 2) you will know I have a secondary interest in working on Python. I am looking to integrate Python into the engine. This just gave me an opportunity to have a look at the wxPython code and bindings in detail. That actually is a totally different topic in itself and I will go in to further details in the third part of the series (whenever I get around to writing it, probably soon). Coming back to wxPython, it’s been about 2 years since I worked on wxPython and I liked it then and I like it now.

Today wxPython is probably the best python GUI according to me. I haven’t worked with PyQt but I had tried messing around with PyGTK. PyGTK to be fair is kinda OK, but is less supported than wxPython. Also the fact that wxPython is far more extensive in widget and framework support than PyGTK, makes the former a more attractive choice. PyQt was just out of the contention for me because of 2 things, a) It has a very shady license, I think it is not LGPL compatible. You can’t trust it enough to use it in commercial product without breaking some license somewhere, too controversial! AND b) Qt is just such a horrible framework! I know people are going to disagree with me on this one, but Qt’s moc compiler thing just makes me cringe. I have worked on a large project involving Qt and C++, and those moc_* files can be a nightmare at compile times. Besides Qt uses archaic and redundant C++ practices to maintain compiler compatibility. So I generally tend to “run away” from Qt and Qt projects.

Another challenger to wxWpython is Tkinter. Tkinter has a limited set of widgets, or rather had, at least at the time I was using it and that was a while back about 4-5 years ago. Although Tkinter is very easy to learn, for even a moderately complex GUI, you end up writing horribly complex code to get all functionality in. Not the ideal choice if you want to scale your GUI application to changing requirements. In all fairness, Tkinter is probably very easy to pickup, far easier than wxPython. In its support it also has better documentation than wxPython. wxPython is lacking in proper documentation. All the documentation you have is for it is C++ wxWidgets documentation. In fact I found it easier to work with the python library because I am pretty conversant with wxWidgets. That could, and I think I very well will be a sticking point for a person who has no knowledge of C++ and/or wxWidgets. However help is at hand and you can just buy this book.

Looking at a broader perspective of rapid cross platform development there are other options as well. Java does provide a good alternative, but I generally feel that Python is far better suited for RAD GUI development. Java GUIs can sometimes be slow and I mean real slow. I have no clue why this is the case and I have nothing particularly against Java but, I have yet to find a decent Java GUI library that could solve all my problems while developing cross-platform. Another contender is C# and Mono, but I have no experience with Mono so can’t say too much about that. However, from what I can tell, Mono has some way to go before it can be production stable.

Whatever you use, try to stay away from C++. I often find a lot of resistance to that idea of “not using C++ for GUI development”. Using C++ for cross-platform GUI development is just not an option that one must consider these days. Especially if you are building a non trivial application and since you have other options where you can increase production times considerably. GUI can get complex very quickly far more quickly that you think. Similarly GUI code can get pretty extensive very easily, especially GUI construction code. While you have GUIs that operate on resource scripts (something like .rc files under windows), refactoring any GUI can be nasty. C++ does not scale well to a lot of refactoring. You generally end up with bugs and crashes all over the place. I am saying this again, try to avoid C++ while developing cross platform GUI projects.

wxWidgets can use an XML resource file for GUI and so can wxPython. I had never used it before but gave it a try for this project. I was more than impressed. The XML resources editor (XRC) takes a bit of getting used to, but once you get the hang of it, making resources like dialogs is pretty easy. I am pretty familiar with the layout systems, but still it took me a while to figure out what went where to get a proper look to the UI.

An example of dialog in wxPython.
(Windows)

Developing an application with wxPython turned out to be a good experience in the end. I guess it went well and I am pretty happy with the results. It’s not trivial, no GUI development is but my decision to drop Java in favor of Python was a hit!