Giving GTK a chance

14 February 2021
Although I think I first came across GTK back in the early-2000s the earliest I remember seriously using it was in 2010, and this kicked off a dislike of it that has persisted to this day. However in the last few days I decided to take a serious look at GTK3, in short because I was considering using it as a platform for a reimplementation of the wxCatalogue electronics catalogue tool. At the very least my view of GTK has improved even if come of my prejudices against it have been validated.

Accumulated dislike of GTK

Although it initially attracted me because it was the only viable cross-platform tool-kit that was C-based I had for a long time had a grudge against it, mostly stemming from using Gtk2 under Windows back in 2010-2012, and my prejudices were not helped by a brief flirtation with GTK# that later turned to disillusionment when it became clear how badly maintained it was. GTK's reputation for breaking backwards-compatibility even between minor versions was not lost on me. However many of these shortcomings are historic and co-dependent on conditions that do not apply these days but the legacy has not entirely gone away.

GTK documentation problems

I am not sure if I made much use of GTK beforehand but certainly in mid-2010 I was already developing a dislike for it due to issues with documentation, and if anything it has got worse since because the internet is now littered with incorrect information that refers to older versions. For instance the vast majority of code snippets related to drag-and-drop mention gtk.TREE_VIEW_DROP_INTO_OR_BEFORE whereas for GTK3 the correct equiconstant is Gtk.TreeViewDropPosition.INTO_OR_BEFORE. I think a large part of the problem is that PyGTK was replaced with the slightly cryptically-named and much broader-scoped PyGObject in Python 3, and I suspect that Python2/GyGTK projects tended to be either abandoned or rewritten for other platforms rather than converted to Python3/PyGObject.

From a documentation perspective the underlying C-based API has the least problems, and from the few I have looked up so far looking like functions and structures carried over from GTK2 being unchanged in GTK3. In fact some sample GTK2 code only needed the changing of the pkg-config parameter to build for GTK3. However a lot of documentation is little more than description of function descriptors — for instance the TreeView drag-and-drop documentation pretty much just says that the off-the-shelf TreeStore model handles all the book-keeping for you, which is not much use for those wanting to implement custom models.

Glade irritations

While wxWidgets XRC allows controls attached to different root-level widgets to have the same name, Glade enforces a global namespace which is rather irritating. Menus are also a particular sore point with Glade because they are positioned by a properties spinner that contains the position number, rather than simply drag-dropping them in the GUI structure tree. Glade is a lot more polished than wxFormBuilder but on the whole I think the latter is a much better thought-out tool whereas Glade seems taken in by modern Menubar-less design ideas that I hate.

Portability headaches

Back in 2010-2011 my then-company's product used GTK2 and a large portion of the products that shipped were based on Windows rather than Linux, and I ended up doing a special build of GTK which no doubt added to my dislike of the tool-kit. Having all the bits in place that allowed company business logic to look and feel how it should was an ordeal, whereas wxWidgets was a comparative dream on just about all counts. Maybe it was because wxWidgets was based on how Windows did things and at the time I was still doing a significant amount of Win32 API development.

Spurious error messages

No matter what I do the program emits some warnings such as the ones below that are difficult to track down let alone get rid of — as far as I can tell this example is caused by sometning in the Glade layout file, which begs the question why doesn't Glade check for and correct these issues.

./ElecCatalogue.py:524: Warning: g_value_transform: assertion 'G_IS_VALUE (src_value)' failed Gtk.main() ./ElecCatalogue.py:524: Warning: unable to set property 'text' of type 'gchararray' from value of type '(null)' Gtk.main()

Licencing issues

Companies I have worked for since 2013 have generally been very hot on software licence compliance, but back in 2011-2012 my effort to maintain “auditability” was very much against the grain, and in my first job plagiarising of code was much to my disgust at the time actively encouraged. I am not aware of any major BSD-licenced GUI tool-kits but almost uniquely wxWidgets has a linking exception, which is something I started to appreciate when I had to do a special build of FFMpeg purely to make sure that it was Lesser-GPL rather than full-blown GPL. I only stopped worrying about this when I stopped using Windows completely.

The up-side of GTK

On Linux wxWidgets is more or less a front-end to GTK and since Linux is virtually the only platform I use these days, I concluded that there would be benefits to using GTK directly. As a proof-of-concept I rewrote the drag-drop of the main window and most of the functionality of the add component dialog of wxCatalogue, which between them account for pretty much all that required for a full rewrite, and overall I have little desire to look back at the old wxWidgets-based codebase. I even managed to closely replicate the expander icons without too much effort, so while the parts I reimplemented are not identical to what wxWidgets shows, I probably could make them so if I really desired to.

In a relatively short period of time I recreated the major part of a program I make significant personal use of, minus long-running sore points, and in a programming language which I think it much better suited for the task. I don't see how this can put GTK in anything other than positive light, particularly as the major reasons for sticking with wxWidgets rather than going to GTK are Windows portability and licencing concerns, which no longer apply.

Looking forward

While any rewrite of wxCatalogue will use Python and fortunately enough there is a working Slackware 14.2 SlackBuild for PyGObject, any program that I expect to still use in many years' time will most likely have to be built statically, which basically means writing it in C or C++ somewhere along the line. However if I am to get back into C programming with the GTK tool-kit my inclination is to go straight for GTK4, which is something in itself I would most likely not do until Slackware 15 ships.

For as long as I can remember there have only been two desktop-based GUI tool-kits I have had any long-standing regard for, Win32 API and wxWidgets, and of these only the latter is one that I expect to make any future use of. However since wxWidgets in Linux is a wrapper around GTK I need to decide whether I should drop wxWidgets completely and simply use GTK directly. At the moment the answer is “no” but not that long ago the answer was “NO!” so I have moved a bit in the direction of “yes”