Comment 2E0 Why not Qt?


The Future of GTK+


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.


Time Reason Points Voter
2014-07-10 03:07 Informative +1

Junk Status

Not marked as junk