Story 2014-07-09 3Q6 The Future of GTK+

The Future of GTK+

in code on (#3Q6)
story imageOnce 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)
Reply 10 comments

Could we just fork it? (Score: 1)

by on 2014-07-09 22:28 (#2DQ)

I can't say I know all that much about graphical toolkits, but could we just fork GTK, using GTK2 as the base? Most of my applications use GTK2 and I'm pretty happy with this state of affair. The GTK3 ones tend to break things. But I really prefer the modular nature of GTK. When I need to use other toolkits, it tends to pull 50 libraries...

Re: Could we just fork it? (Score: 2, Interesting)

by on 2014-07-09 23:34 (#2DS)

The code is easy enough to fork, but the trick is to have an active developer team that can then continue its development. GTK has traditionally been developed by paid Redhat employees who also work on Gnome.

Mate is a project to maintain and continue development of Gnome 2 (including GTK2) and seems like the most likely place for such a task.

KDE / Qt Always Better (Score: 1, Interesting)

by Anonymous Coward on 2014-07-10 00:18 (#2DW)

In my opinion of course. GNOME has always, even through the drama of KDE4, seemed klunky and inferior.

I suspect it's just that KDE's early pre-GPL licensing problems gave it a bad taste in people's mouths, even though it's always been a superior environment.

So from a sports-team point of view this is pleasing, but from a real person point of view it sucks to hear that 3rd party GTK applications are being strangled.

MATE does seem like the appropriate forking point, but are those developers really interesting in taking on that big a challenge in addition to simply maintaining a UI?

Re: KDE / Qt Always Better (Score: 1)

by on 2014-07-10 00:30 (#2DZ)

I agree with the GNOME sentiment, but one of the strengths of the GTK+ toolkit was that it wasn't limited to just GNOME - it was a standalone library that an alternative DE could easily use. XFCE and LXDE are example desktops, while a rather large majority of GTK+ applications didn't touch the GNOME libraries at all.

Re: KDE / Qt Always Better (Score: 1)

by on 2014-07-10 01:18 (#2E1)

To me it looked like GNOME2 had better polish in both themes and apps, while KDE3 had better underlying tech (Qt, KIO, DCOP, KParts etc). It would probably be less of an effort for GTK theme writers to build a good looking Qt theme than to keep a themable GTK library alive, since the GNOME3 developers seem hostile to the very idea of theming the desktop.

I don't think the GNOME3 developers are necessarily wrong: you can't have a highly customizable desktop that also provides a consistent and instantly recognizable look and feel. KDE chose customization and accepted that not every combination of settings works equally well and that every distro's and person's KDE desktop looks and feels slightly different. GNOME3 seems to choose the other option, but doesn't go all the way and keeps a bit of customization limping along. In my opinion it would be better for everyone involved if they would just cut out the theming functionality altogether: the GNOME devs get to build their single consistent user experience while the theme authors would be spared the frustration of their themes being broken in every new GTK release.

Why not Qt? (Score: 2, Informative)

by on 2014-07-10 00:56 (#2E0)

Around the year 2000, a big reason GTK became popular was licensing issues with Qt. But Qt has been licensed under LGPL (same license as GTK) for 5 years now and under GPL for a lot longer.

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.

I'd choose neither (Score: 1, Insightful)

by Anonymous Coward on 2014-07-10 09:06 (#2E7)

If I was in the same situation as these developers, I'd choose a 'Desktopless' toolkit. So-called 'Desktop Environments' are a total failure in Linux. Both the KDE and Gnome guys are trying to implement an operating system solely in userspace and it doesn't work so well.

Take the basic task of automounting for example. On my Gnome-based system (XFCE, which somehow makes use of GNOME daemons), it never works right. Sometimes it doesn't mount at all, sometimes it immediately mounts something I just unmounted etc. Come on man, it's 2014 and we're still dealing with this?

Since this stuff doesn't work so well, it changes constantly and you have to chase the GNOME/KDE guys just to make your application compile.

Tying your application to a desktop environment is a sure way to kill it. Now they're complaining about the GNOME stupidity, who knows KDE won't do the same thing? Money-backed big projects tend to attract tons of hippies and they really know how to mess up a good system. See firefox, gnome, systemd, chrome, etc.

GUI toolkits are a done deal. There is nothing left to be discovered with the current hardware. You can port them to newer features of graphics cards or X11 extensions but that's about it. The endless tail chasing Gtk+ and Qt does is nothing more than make-work. Come to think of it, if I just want to display some dialog and get some input, what drastical change has occured since the year 2000? Why can't we just use something done at that time for these basic tasks? Where is the need for updating the button-drawing code for the n-th million time?

I'd definitely go for a desktopless toolkit. There is nobody to mess it up and my program is likely to compile for a long time. There are tons of these: fox, fltk, wxwidgets, even java swing is a better choice than gnome+gtk. If you want advanced features like video playback or HTML display, it's a different matter but for an application which only needs standard controls? I'd never touch GTK or Qt.

Re: I'd choose neither (Score: 0)

by Anonymous Coward on 2014-07-10 17:31 (#2EH)

That sounds great and everything (I didn't know for example that Audacity used wxwidgets) until you got to "advanced features like... HTML display".

Huh? HTML display is required of even the most rudimentary applications these days. (Though of course can often be done by calling a default rendering engine.)

Maybe I misunderstand you? I like the general idea that tying one's self to a DE is a bad idea for cross-compatibility. I've tried running KDE and GNOME apps in Windows and it's not pretty (or particularly functional).

Bring back Gnome 1 (Score: 2, Informative)

by on 2014-07-10 13:30 (#2E8)

I love the guy who starts out this post ( with "At the risk of turning this into the 'bad news blog'." That's telling right there - most of the news and changes in the world of GTK/Gnome involve taking things away that used to be there. They're driving that car right over the cliff, despite warnings to the contrary, and with an apparently even stronger suicidal zeal.

See ya later then. I was never a fan of Gnome after Gnome1, although I concede it was always the nicer looking system, visually and graphically. Gnome 1 was still a hacker's paradise, with the Sawfish window manager and tons and tons of configurable hackability. That's what I like in a DE. But I've always been a KDE guy, for other reasons (and still kind of prefer KDE3 to KDE4, actually - go Trinity!).

Sorry to see the GTK project get hijacked by the crazies over at Gnome. They sure made a mess of the Gnome desktop; too bad they're going to take GTK down with it as they sink the ship. The post I linked to above really is telling. They've lost all touch with reality and/or user needs. Meanwhile, QT is pretty cool, professionally managed, and although it's strongly tied to KDE, it hasn't been taken hostage by it, which means even if KDE screws the pooch there's hope the QT toolkit will remain useful and functional. If I'm not mistaken, too, it's getting faster and lighter weight/lower memory intensive. That's all good.

I've got other problems with the KDE desktop (like Akonadi and Nepomuk and their perpetually sucky rewrite of kmail) but the toolkit isn't one of them. Secretly though, I really wish the Etoile people would ramp it up and give us an interesting, third alternative. Meanwhile, I'm interested in checking out the new LXDE and the QT-Razor or QT-Light projects (or whatever they're called now, I forgot).

Re: Bring back Gnome 1 (Score: 1)

by on 2014-07-10 13:38 (#2E9)

Another great quote from (I emphasized the good part)
Yet as I read some of the GNOME developer comments below, I was given to believe that this breakage stems from a Microsoft-like climate of preventing users from customizing their systems, and deliberately breaking the work of others so that your ‘brand’ is the best. Anytime I hear the word ‘brand’ being used in Linux, I know something valuable is being poisoned.