The Future of GTK+
Once hailed as the most free and widest used X toolkit, the future of GTK+ now looks dire. The gnome developers have essentially highjacked the latest version, GTK3, and are actively destroying all ability of non-gnome users from using this once popular toolkit. I find this very unsettling, as I have developed a number of my own desktop applications using GTK+ through all three of its major versions. I've always preferred GTK over QT, but with some of the recent changes, I'm starting to change my mind.Of course, I'm hardly alone in this opinion as many other projects have abandoned GTK in the recent months. Take Audacious, for example. This GTK music player has had increasing troubles with the gnome developers screwing things up. So many troubles that they are now planning on switching toolkits rather than further deal with the upstream management. Although they had a functional GTK3 port, they've officially reverted back to GTK2 until they can properly refactor their entire program into QT.
I've been a happy user of the XFCE desktop environment for the last few years. This light and easy to use UI gets out of the way and just plain works. However, the interface toolkit of XFCE is tied to GTK2 and its authors have no clear upgrade path. A similar project, LXDE, has also seen the writing on the wall and are well into a rewrite project that switches their preferred toolkit from GTK to QT.
Although the "G" in GTK stands for "GIMP" this popular image manipulation program has yet to release a GTK3 version. Even Linus Torvalds' own pet project, Subsurface, has recently abandoned GTK for QT. Is the future of GTK+ programs doomed? Can a revival project, such as Mate, takeover maintenance of the GTK toolkit for the rest of us? (let the gnome people screw up their own fork)
More language bindings has been mentioned as a reason, but are there languages one would want to write a GUI in which lack Qt usable bindings and do have usable GTK bindings? I once tried programming GTK in plain C, but trying to use objects using library functions and macros instead of using an OO language just felt awkward and led to hard to understand compile errors. I must say that I found PyQt a bit awkward as well, since it never really felt like you were programming Python: it was always clear it was Python code talking to a framework written in a different language. So it made me question the usefulness of GUI toolkit bindings in general.
Qt has better cross-platform support than GTK. The last time I used a GTK app (Inkscape) on Mac OS X, I had to run an X server and it looked really out of place; a quick web search suggests the X dependency is gone but integration with the native desktop is still minimal. GTK on X-less (framebuffer or EGL) embedded Linux is unmaintained as far as I know. I don't know the state of GTK on Windows because I haven't seriously used Windows in a long time.
Qt has a strategy for supporting touch devices (Qt Quick), seems to be on track supporting Wayland and is adapting its drawing model to better fit modern graphics hardware (scene graph instead of immediate drawing). GTK could be forked to keep compatibility with themes and non-GNOME applications, but it would require a lot of effort to keep up with current trends (not all of which are hypes that will blow over).
Another thing Qt has going for it is that the KDE libraries are being modularized, so instead of one big set of kdelibs there will be a lot of smaller libraries, some of which depend only on Qt and some which are connected to a whole lot of other KDE libraries (there are 3 tiers for different allowed dependencies). This means that some of the functionality developed in the KDE project becomes available to Qt applications without those applications having to tie themselves to the KDE desktop.