Gtk Rant

I've thoroughly had it with Gtk and PyGtk.

Before starting work on a project that was using and needed to be delivered in PyGtk, I was still under the illusion that perhaps Gtk (and its Python port) may still yet be the best of the toolkits out there, just that I'd never really dealt with it for anything before. But now that I have used it extensively, I have to conclude that this is not the case.



While before this, my world-view of UI toolkits looked something like (going from worst POS ever, to nice):
(Microsoft Common Controls), Crappy "Free" widgets from download sites, FLTK (+ other crappymatic toolkits still stuck in the 1980's, with their heavy bevelling and blocky appearances), wxPython, Visual Basic, Java Swing, PyQt

For those interested:
- Blender's UI toolkit sits on the same level (or slightly above) PyQt, depending on which aspects you look at. Though, then again, I am slightly biased in this regard ;)
- CSS (not technically a UI toolkit, but used for a lot of web-related things, in particular affecting the appearance of UI's on web-based apps) sits just above MS Common Controls in my books. It is a very vile, stinking pile of insanity. The original intentions might have been heroic, but the results are pain inducing, and not really something you'd hope on anyone to try and debug (though it still comes second to concurrency bugs by a long shot still).
- wxPython ranks so lowly since when I used it, it was quite unstable. It was also poorly documented, and support channels were generally unresponsive. Things may have improved since then, but I haven't checked back in the meantime.

After my experiences over the past few months, I have to conclude though, that GTK sits just below wxPython, but not quite (unless you start scratching at the edges of its API's or the uglier themes available for old-time hardcore penguin geeks) at the next level down. It has set a new low point for toolkits that I might consider for actually trying to use to get something done.

Exceptions?
Now, you must be thinking, surely there must be some exceptions to this? Surely it mustn't really have been such a bad experience for everything?

Fortunately, there are some exceptions which only slightly redeem it from falling into the category of stuff to be avoided at all costs:

• Adjustments - I've been using these a bit, and IMO they are great. Perfect for ensuring that values, extents, etc. get synced between different number-editing widgets painlessly. 
• The only decent purely C-based option on Linux (but also on other platforms, and for free). Everything else requires using C++ and using some weird extra preprocessors that they may require.
• Startup speed vs Qt? At one point I was finding that Qt apps started up slower, but recently, I've been finding the opposite. Nevertheless, do your own tests in this area.

The Bad Stuff...
Now, there is quite a long list of things that annoys me about this toolkit. Otherwise, I wouldn't be writing this today!

• PyGtk documentation is a mess. Outdated tutorials suggesting use of deprecated methods, deprecation warnings plastered everywhere with varying version numbers (but in most cases, seemingly wrong) but yet hard to associate what is related to what, robotic-help descriptions for ALL the various functions (better than the absent docs for many Qt functions and all the wxPython ones, but worse than the insightful and helpful docs for the Qt functions that do have them), weirdly ordered API function lists, and a lack of good info on how things related to each other.
• Ugly widgets. It could be argued that themes and different styles are meant to be used to solve this, with end users getting to choose how they want their UI's styled. But considering that 90% of the the available themes are still butt ugly bevelled-box beasts for yesteryear, and that you're perpetually one API call away from turning a widget into an eyesore, this is quite an issue.
• Extreme difficulties for customising appearance of widgets. Although there are valid concerns that you shouldn't go around trying to customise every single widget you deal with, sometimes, there are situations where some minor tweaks are in order. Perhaps one button just needs to be a different colour, and not even a hardcoded colour, but rather just a darker shade taken from the theme defaults. Well, GTK makes this REALLY HARD. You have to jump through hoops to even get some changes to appear, but then, you've just managed to blow away all the general theming niceties that you didn't mind and are stuck with a very very ugly widget that only partially looks how you intended. And that is not to mention that you're still just hardcoding colours and hoping they don't clash with the target user's themes, since it's impossible to retrieve a set of global colours that work and can be used. There's also the problem of widgets that are only partially customisable, and only in areas that matter the least or which end up causing the widgets to look butt ugly.
• Clunkiness of creating new widgets. The few times that I've tried so far with GTK have been quite slow-slogging affairs for this crucial ability. Trying to basterdise the toolkit to give you what you want is just not an easy thing to do, even if you're willing to code it all yourself! Maybe that's why the existing widgets are all so bad, as it's such a pain to create them.
• Buggy comboboxes. I've slowly become increasingly annoyed with the combobox dropdowns that GTK offers, both while using other GTK apps, but also while testing my own work. In particular, the tendency for the boxes to open up full vertical (or at least in some apps), and with a massive gap between the first item in the list and where the mouse and combobox were located when the dropdown is activated (it seems to try and place the first item something like 1/4 the way up the screen or so). Compounding this is the fact that releasing the LMB means that the dropdown immediately exits (apparently it treats this as a confirmation that whatever is under the cursor is the intended target), so you're forced to hold LMB while trying to scroll with the other fingers.
• Everything needs to have show() called on it first. Everything. No other toolkit in the world that I know of requires coders to explicitly make them visible after adding them to some layout manager. It's just toplevel things like windows that deserve this!
• "set_sensitive()" and "get_sensitive()" - WTF? What everyone else calls "enabled" is called "sensitive" here, with things like "sensitize this widget". Gah!
• Showing message boxes and dialogs is a pain. It's such a pain, that I have a set of utility functions which are needed to wrap the API types, call these functions to build up the dialogs, show them, and destroy them. And the worst part is, everyone else also ends up doing this for themselves too (but many just get lazy and copy the code around all over)!
• Labels need to be wrapped in GtkAlignments to be useful/usable. In what other widget toolkit do labels default to being centered, and having to be forcibly wrapped everytime you want a left-aligned label for adding a label beside something? Madness!
• [EDIT 22Feb] - I've just found that in fact, there is a simpler way (though my comment about the need to even have to do this stands!). Simply do:
  

  lbl = gtk.Label("Label Text")

  lbl.set_alignment(0.0, 0.5)

  OR (1.0, 0.0) for top-right, (0.0, 1.0) for bottom-left

• In most GTK-based apps (though Inkscape seems to have figured this out and hacked around it), +/- keys for zooming in/out are not mapped in a user-friendly way. For instance, in many apps, Shift + must be pressed to zoom in, as GTK treats the + and = symbols on that key separately. In most cases, that wouldn't be an issue if the +/- keys on the numpad were hooked up for this purpose too.
• The defacto GUI designer (Glade) is an example of poor and ugly design itself. Last I checked, these guys didn't even know what padding was, when, and where to use it. Case in point: their properties panel tabs thingy was one of those ugly programmer contraptions with zero padding on anything, so the edges of widgets would touch window frames, and text would be hard to read due to this. The underlying code was probably of the sort that I've previously blasted as being ugly formatting (the ones where spaces are missing, catapillar ifs abound if they're not using the verbose GNU C style that is). But then there's that contentious issue of just heaps of different windows floating around. It's no surprise that people are going to have GUI design problems, when the tools that they work with and are surrounded by daily while designing these are ugly messes, and they only end up absorbing all this negative energy into their work, further polluting the world.
• Too many confusing layers of API's.  Cairo-what?!
The final straw But perhaps, the final straw came tonight, when after a two week break from touching my PyGTK install on this machine (and perhaps after one particular software install which I can no-longer identify), PyGTK now refuses to run on my computer, giving the infamous "glib cannot load dll" error. Several attempts with the installer have been largely fruitless. This stuff is crap, and I'd seriously advise against using it for anything again, especially for new projects being started from scratch. Hell, I'd even be willing to code a UI in Java Swing of all the toolkits out there! I know I've bagged a few times in the past for being so ancient in some areas that you have to customise it heavily to make it tolerable to use, but importantly, it LET'S YOU DO THAT if you so wish, and it's easy to bash it into shape (and to put in hacks for the few threading issues it has). You probably don't even really need to code in Java anymore, if you take Jython or some of the other JVM-based languages like Groovy. But GTK and PyGTK is something I'd be giving a wide berth from now on.