GTK+ vs. Qt, from a teenage developer’s perspective

Ah, the good ol’ Qt vs. GTK argument. It’s one that seems to come up in my head a lot when I want to start making apps for Linux or for cross-platform apps in general. I’ve been using Python and Swift lately, so I’ve been more at ease with the programming; hence, I’m not worried about APIs as much with these frameworks. However, I always seem to fall back to one of these, and it’s a shocking move, considering that I will always seem to fall back to GNOME 3.

Note: This isn’t an argument over GNOME and KDE. I like both environments very well and can’t wait to see Plasma make it to Wayland in a stable state on Fedora.

What are we talking about, anyway?

For those that haven’t heard of Qt or GTK+ before, both of these are toolkits that are used to create user interfaces; both are responsible for making menus, title bars, windows, buttons, etc. Both of them have the ability to work across different operating systems.

GTK+ (GIMP Tool Kit) is commonly used on Linux systems that work with the GNOME desktop environment, though it works nicely in other environments like MATE and Budgie. Recently, GTK+ 3 has been focusing on making their interface work more nicely with GNOME 3, “simplifying” the interface quite a bit; iPad users would probably feel at home with GTK+ 3 apps.

On the other hand, Qt retains the standard app with menus, title bars, and the overall traditional “desktop app”. Qt is commonly used with desktops like KDE Plasma and LXQt. Lately, they have been expanding to Internet of Things and mobile devices, creating QtQuick for this purpose. Qt is more extensive in what it’s doing compared to GTK+, but the official bindings are for C++, which can be a little bit challenging.

My experiences with GTK+

Bendy
Jadey for GNOME is written in Python and GTK+.

Before I go into depth with Qt and why I prefer using it than GTK, It’s best that I describe my experiences in working with GTK+ first. Currently, I am using GTK+ to create Jadey for GNOME. While working with Python itself isn’t too much of an issue and I haven’t really had to touch any of the configuration files inside of the GNOME Builder project, I will admit that attempting to work with GTK+ is annoying. For instance, here’s how to add a button to the header bar in GTK+ via Python:

button = Gtk.Button()
 icon = Gio.ThemedIcon(name="mail-send-receive-symbolic")
 image = Gtk.Image.new_from_gicon(icon, Gtk.IconSize.BUTTON)
 button.add(image)
 hb.pack_end(button)

Given that I have little experience in GTK+, let alone Python, it remained confusing as to how I was to get my app to look the correct way. However, having to continuously create buttons to add to the toolbar and identify everything at every single step of the way is quite annoying.

My overall opinion of GTK+ may feel skewed because I’ve had more experience with Qt, but I still didn’t get the best developer experience out of the toolkit, especially since PyGTK was replaced with PyGObject.

So why Qt?

Frame-30-08-2017-07-24-34

Given my horrible first-impression experience with GTK+, I’ve grown accustomed to the frameworks and language of the Qt toolkit. When comparing my Qt code to my GTK+ code, I’ve found that Qt has been much easier to work with. I’ve grown fond of this framework, no matter how “archaic” or “old-fashioned” it is. I’ve even begun to use apps that are built with Qt; once KWin has stable support for Wayland, I may even switch to KDE Plasma. Nonetheless, there are a few reasons why Qt stole my heart instead of GTK+:

Qt is traditional and modern.

Let’s face it; the new language for interfaces started to come about because of smartphone and tablet innovations. We wanted everything to come together in a universal interface so no matter what device we were on, we would understand how to use it. Certainly, Material Design and Fluent Design pull it off well, making it feel universal everywhere.

Qt has two different types of interfaces: Qt Widgets, the version of Qt that I have been referring to, and QML, a version of Qt that scales across all types of devices. QML does a great job at creating applications for all kinds of devices, but I have yet to really try working with QML and Python. Qt Widgets, however, is the traditional layout that works best on desktops. It’s what everyone is used to, and it hasn’t failed yet. Qt knows well the boundaries in interface language and it doesn’t try to consolidate everything.

Qt looks nice on any platform.

I’m not one to be really picky if my apps have to have a certain theme to them, but it’s nice to know that Qt works across different desktop platforms without looking completely ridiculous. I started working on Octodollop in Fedora 26, and it looked quite decent. When I migrated my work temporarily to my iMac, it retained the look and feel of macOS’s Aqua interface; it simply fit right in.

Compare this to GTK+. When I started working on apps with GTK+, the theming was just weird. While it looked nice under Linux regardless of whatever theme I was using, seeing it under macOS was a different story:

 

gedit-9
Gedit under macOS. Image from Softpedia.

Although this particular screenshot of Gedit doesn’t look too horrible, it didn’t look right compared to all of the other macOS apps. When I attempted to create a GTK+ app of my own in Visual Studio, the interface just looked downright old and unpleasant; in fact, it looked like it should have been associated with a Qt Widgets app because of its old style. It’s interesting how Qt Widgets handles interface language better than GTK+ can despite its traditional interface model. In fact, the theming for Qt doesn’t break every time a new update is released; take that, GTK+.

Qt actually makes sense.

This is more because I have been using Qt with Swift and Python, but looking at the Qt documentation is a lot less confusing than in GTK+. If I need help or need to find the right thing to reference, I can take a quick look at the Qt documentation and I can instantly find the thing I am looking for, despite the fact it’s written in C++. The names of certain objects actually make sense: a menu would be a QMenu and an icon would be a QIcon (compared to an icon in GTK+ being called a Gio.ThemedIcon). Simply put, I can understand Qt a lot better than GTK+.

In conclusion

As much as I could go for GTK+ instead of Qt for things like universal design and better GNOME integration, I’m still sticking with Qt. It works best in my workflow and is a pleasure to use compared to GTK+. Perhaps when things are cleaned up a bit and GTK+ works better for me, I might switch. For now, I’ll take my Qt cake and eat it.

Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s