Qt and GTK are Graphical User Interface libraries used by software developers to add standard user interfaces to applications on Linux, Windows, and OSX. The reasons for choosing one are loosely based on fashion, practicality, and the details of the various releases of each library. There are also alternatives popping up faster than you can evaluate. There are good arguments for both.
Who?
Who needs GTK or Qt? Everyone developing a program with a user interface needs something an the leading contenders are GTK plus Qt. Qt leads among C++ developers as Qt has a native interface for C++. GTK is designed for plain old C and is often the first choice for C. Some people work hard to use GTK in C++ and more people put in the extra hours to make Qt work with C.
Both options have awful histories.
Qt went through several owners and licensing systems, the main reason people avoid Qt. Then Qt moved to open source but maybe not stability, a question holding back some potential users. If you are starting today, that is no longer a problem. If I wrote code in C++, I would now use Qt.
GTK had a brilliant start but is spiralling down into a niche. GTK is up to version 4. GTK 3 is not yet finished to a point where I would consider it ready for use but all the developers appear to have abandoned GTK 3 to work on GTK 4. GTK 4 is a long way from being usable.
The same happens with GTK releases. For example, when I tried to use GTK 3.16, some things from earlier releases were deleted as "obsolete" but not yet replaced with anything workable. GTK used to let you specify formatting in code but started to delete those options based in a replacement by CSS formatting. The replacement CSS often did not work for many releases after the direct formatting was deleted.
CSS formatting requires an element name or an ID or a class. It is often impossible to find any of those. If you do, they may not work for years. Some of the recommended options have never worked in the many years I tested GTK CSS.
When?
GTK and C were the preferred choice for efficient programming. C++ programming was difficult from the perspective of creating small programs as C++ seemed to flood your system with masses of everything. The last time I tested C++, you could start with just what you needed without the Tsunami. I have not yet tested GTK against Qt for equivalent code size.
Rust is now popular as a better alternative to C when you need multi tasking but Rust prefers a new GUI written in Rust. My first attempt at Rust plus the Rust GUI showed the GUI to be limited. Last year, 2024, Czkawka appeared and showed the potential uses of Rust plus the Rust GUI. Unfortunately Czkawka still has interface problems. When Czkawka fixes those problems, I will look at their code and possibly upgrade some of my programs to Rust.
Where?
GTK and Qt are designed for distributions of Linux with a GUI. GTK had the best start and was the winner for years then the Gnome organisation took over GTK and spoilt everything. Qt appears to have a different owner for every version. The latest version has a proper open source organisation managing development.
GTK is the Gimp Tool Kit derived from the graphics used in Gimp and run on every operating system. Gimp appears to be staying with an older version of GTK due to the mess Gnome is making of GTK 3 and 4. The Gnome management appear to be restricting GTK to Linux and only some distributions of Linux. GTK 4 may be unusable everywhere else.
I do not know how the latest Qt works everywhere as I tested Qt applications only in limited systems.
Why?
Some users like a GUI that works natively with their operating system so the application looks like every other application on that operating system while users working across multiple operating system often prefer an application that looks exactly the same on every OS. These two conflicting requirements make life difficult for GUI developers. I chose GTK because Gimp works so well across multiple operating systems.
Programmers like a GUI that works natively with their programming language as development is easier. this is often the deciding factor at the start of development. When a GUI fails to work or fails to tell you how to make it work, another GUI may look better. I chose GTK 3 back at the end of GTK 2 when GTK 3 was available but still in development. Unfortunately GTK 3 remained in development throughout the life of GTK 3. I had to put in lots of work to make documented functions work as documented.
During the life of GTK 3, Qt went from a licensing mess to open source.
Way?
You can test GTK with a C program and a bunch of other languages but C will give you the cleanest closest match. Qt is designed for C++ and works with other languages. Check your first choice for a programming language. Which GUI is the clean neat recommended GUI? Use that option first as you will get the most help and support. Only look at something else when you crash into a major limitation.
Worth?
I do not currently see much value in using a GUI that does not work with your programming language. GUI packages are difficult to learn. The first reason for changing might be working with several languages and choosing the option that works with all the languages you use. You save time by learning only one GUI.
The second reason is to use a GUI that works with an unusual programming language. Rust is an unusual programming language and has a GUI that is supposed to work best with Rust. For rust, I would look at a Rust based GUI as a time saver.
The third option of value t developers is a specific environment. Are you writing a game? Do you want your application to run on Android smartphones? There are niche GUI options for each specific use. If your application also runs outside of the nuche, you might want the most compatibility with the niche code to save you time when redeveloping for each niche.
What?
GTK works for some things. Qt works for some things. In most cases they are similar and the differences depend only on the specific version. I found only one recent technical reason to choose either GUI library.
You use the C programming language for speed. GTK works with C without doing anything special. Qt does not work with C. To make Qt work with C, you have to put something else in the middle and anything else in the middle slows down the C program. I was working on a C program so I used GTK.
I did make an attempt to use Qt on one C based project. You have to download a lot of software to make Qt work. None of it worked due to version incompatibilities that could not be fixed.
This is an example of where one of the GUIs, GTK or Qt, is an easier choice due to a clear cut technical difference. Most of the other technical differences only apply to specific versions or releases, making a technical comparison difficult.
Which uses the least memory?
There are plenty of people pushing Qt as using the least memory. I compared some Qt based applications with their GTK equivalents and the results were varied. The underlying applications varied in memory use more than the GUI components.
GTK supposedly uses more memory because GTK provides more functionality. Qt does less and uses less memory. If that is your logic, then you should also look at Aura and the many other user interface libraries providing less functionality.
GTK can be used at several levels. For example, you can start with the GTK application code or bypass that to work at a lower level. When you compare the alternatives, you get similar comparison problems. As an example, Aura can be used with or without a separate components named Ash.
In the small number of occasions I created anything using GTK, I built up from the minimum, not down from the top. Memory usage was never a problem. From my experience, some GTK and many Qt applications are bloated compared to what they do. They often appear load everything at the start without thinking about what might be useful.
KDE or Gnome?
KDE is a GUI layer for Linux and uses Qt. Gnome is a different GUI layer for Linux and uses GTK. Both went through multiple versions.
I know people who love one and hate the other. I tried to use KDE a few times over and it failed each time. Gnome worked. It seems like a simple choice.
KDE fans are quick to tell me I should switch from Linux distribution A to B to get the best KDE experience. I have at times switched from A to B and still had problems. When I switch from A to B and mention the KDE problems in a KDE forum, the KDE fan reaction is often to tell me I should be using Linux distribution A, not B.
The differences between KDE and Gnome have little to do with either GTK or Qt. Qt applications work in Gnome and GTK applications work in KDE.
When I investigated the most bloated Qt applications, I found the bloat is because the applications include huge chunks of KDE that are unrelated to Qt. There are, sometimes, Qt based alternatives that are not KDE based and run without the bloat.
Google's contribution
Google decided Qt and GTK are both too heavy for Google's use. On ChromeOS, Google started pushing Aura with or without other helper libraries.
Users of Qt and GTK, in application development, both wished their favourite library would be the first GUI to Android and set the standard. Google's actions with Aura killed that hope.
The most GTK or Qt can hope for is to be the first "cross platform" GUI to reach Android. At the rate Qt and GTK are progressing, it is more likely Aura will be ported back to Linux.
The next step might be to convert Qt and GTK to use Aura internally.
OSX
Some of the forums have GTK fans rubbishing Qt based on the problems in KDE. One classic remark was an OSX user complementing KDE by pointing out it is better than the OSX the user is forced to use at work. Based on the few occasions I was forced to use OSX and the many other operating systems Apple as dumped on users, OSX is more reliable than KDE. Working very slowly with OSX is better than not working at all with KDE.
An Apple fan retaliated by pointing out the "highlight" of OSX, the thing that is supposed to make OSX so much better than every other operating system. The fan pointed out what I found to be one of the worst parts of OSX, one of the biggest productivity killers. If I had a working KDE, I would test the KDE equivalent.
Some Qt fans point out that Qt based applications work on OSX as easily as on Linux or Windows while GTK is struggling outside of Linux. This is a strange because one of the most popular GTK based applications runs on OSX, Windows, and Linux.
Windows
Some Qt fans say most Qt use is on Windows. Their logic is simple, Windows developers use C++, not C, and Qt is written in C++, making the match ideal. They do not present statistics to prove their argument. Looking at the software flowing between Windows and other platforms, C, Java, and Python all appear to outweigh C++. Filezilla is an example.
In any case, most of the Linux/Windows cross platform programs were originally developed on Linux. Gimp is an example. Most of them use GTK.
Documentation, examples, and tutorials
The current documentation for GTK is a messy mix of different releases and versions due to, in part, the GTK team making major changes to GTK in the middle of version 3. You have to select the right documentation version for your GTK library. Some versions are missing or very difficult to find.
I have not used Qt recently. Qt fans say Qt is stable within a version but they also complain about major incompatibilities from version to version. The documentation appears to be good within a version.
The main problem I find with GTK is the lack of usable examples. Their tutorials only show a narrow range of examples that were of little use for my recent very simple application. Their reference documentation does not show how you would use the code. They need something like the examples of use shown in the PHP reference documentation.
The limited GTK documentation added about twenty hours to the application development including time wasted using the GTK Application class. The class is recommended in the documentation but all the class did was add bloat and complexity. I wasted about six hours changing the application to add the Application class, many hours trying to make the class do something useful, then an hour to revert it back out.
Latest release
I want GTK for application development, not experiments. I use the GTK stable release, not the latest unstable release, because the GTK stable releases are already too unstable. I doubt you could use their unstable releases for anything.
The latest stable release, when I start my last big GTK based program, was GTK+ 3.22. I do not know why they call it GTK+ instead of GTK. Looking in the source code library, there was a GTK+ 3.22.30 that was nearly a year old. Development on 3.22 appears to have stopped log before 3.22 was ready for use. Maybe 3.22 reached a point where it worked for some small tests, or, like some previous releases, they just stopped and moved on to a new release.
For GTK+ 3.22, you needed ATK 2.26, Gdk-Pixbuf 2.36, GLib 2.54, GObject-Introspection 1.54, and Pango 1.40. If GTK was too unreliable and unstable, you could use Gdk and Glib without GTK. I could not find working examples of Gdk or Glib for the things I needed.
GObject
GTK uses the Gobject code to emulate some of the features of C++. You could use GTK in C++ via an interface library but Gobject is not really compatible, making for two sets of resource draining overheads. Life would be easier using Qt direct in C++ as there would be more code examples.
GTK documentation would be almost useful if they explained how they use Gobject and the differences it makes to your C code. GTK would be vastly improved if there were useful code examples in the GTK documentation. GTK really needs some excellent documentors.
Big Blue
A few years ago, a publisher asked me to write articles on GTK for Big Blue (IBM). After I started writing, they wanted "academic" articles. Based on the feedback, they wanted articles containing a lot of detail but did not want the articles to be informative or interesting to read. I would have been restricted to reproducing the existing GTK documentation and just replacing 6 word sentences with 25 word sentences. I turned down the contract as I was not allowed to write documentation useful to me when I first tried to use GTK.
My version would have helped both an advanced developer and a "slightly more than beginner" understand GTK. GTK's version appears to assume you are going to read and understand the GTK code or already know enough about Gobject and every other component to not actually need the documentation. The GTK documentation is little more than an index to the code.
There are other publishers producing GTK documentation and some of it looks useful. Unfortunately you have to use exactly the right version and release of GTK to make the examples work.
The long term
Qt suffered from an unknown future due to ownership and licensing issues, something that should now be fixed.
GTK is in development version hell. The development process needs leadership and direction. Releases could then be backward compatible. New releases could make things better instead of just painfully different. I think Qt may win.
Do not blame the Qt or GTK code for bloat in Gnome or KDE or any application. Both Qt and GTK can be used in bad code and both have options to use lower level code to avoid bloat, as proved by both having excellent example applications. Both may disappear under the flood of new GUI libraries due to their long term unsolved problems. Both Qt and GTK need major overhauls to their direction, development, and compatibilty before either can be the final solution.
- Log in to post comments