The shift from GTK-2 to GTK-3 has caused frustration that I think I’ve talked about here before. Much as Americans have historically hyperbolicly hinted at moving to Canada (especially now), I have on occasion talked about migrating preferred toolkits to QT. But… maybe this is actually gonna happen?

Back in the times of QT 4, I noticed that the (then GUI) QT settings configuration tool had an option to just use my GTK (then 2) theme. Set and forget, and my desktop looks all smooth and integrated. I was reading about something mostly unrelated when I learned that QT5 still has this feature. There’s an environment variable - QT_STYLE_OVERRIDE - that I can set to “gtk3”, and then I’m back to not worrying about QT theming.

But I’m still stuck worrying about GTK3 theming because there wasn’t backward compatibility there. Turns out, though, that you can also set this variable to “gtk2” and yup, it reads the GTK2 theme. Amazing.

And I’m painting (or trying to) this as if it’s some huge revaluation, some accident, some overlooked bit of code, and while it’s true that I had to install another package (qt5-style-plugins in deb-land; no second hyphen if you’re in rpm-land), it’s really not. I just missed it because I never looked. It’s so hard to not use the GNOME suite components that it never occurred to me to look at what KDE was building on.

Nonetheless, I’m reminded of Steve Jobs introducing CD burning onstage. The disk finishes burning, and the machine ejects it; everyone starts clapping, and he turns around and says something like: don’t applaud, this is how it should be. Of course there’s compatibility six ways to Saturday; why would there be anything else?

I really don’t have an answer for that. QT is of course incentivized to have such a feature in much the same way that predominantly-Linux software is incentivized to have Windows builds: meeting the users where they are. But it doesn’t explain why GTK lacks this. It’s not like the old code stopped working; I still have GTK2 applications, as does anyone who uses chromium.

I did go though a couple tutorials, and while not everything is sunshine and rainbows… this is pretty good. I can totally work with this. I am working with this. Things like the slots field of classes, which confuse indentation tools and syntax highlighters alike, and the magic object macros without semicolons, are irritating but liveable. For that matter, the C++ is irritating (because I don’t know it), but even that’s not really a problem since I’m going to be using the Rust FFI anyway.

The buildsystem, though. qmake, which half the time I typo as “qtmake”, is a right piece of work. Near as I can tell from reading other people’s tutorials, the expected invocation goes something like this:

  1. qmake -project. This fails if you named files in a way it didn’t expect, like “foo.c++”, and busy-loops forever if it can’t find any files. (There is no way to set custom file extensions that I have found.)

  2. Fix qt.pro. I think every time I have needed to add the line QT += widgets to this file and I don’t know why. Possibly wishing to avoid trying to parse C++?

  3. qmake. This spits out a Makefile, if all goes well. There are I think some warning flags that can be set here as well. Now might be a good time to mention that this tool doesn’t have a man page; the Debian packagers generated one out of qmake -help (as is done when upstream doesn’t provide one).

  4. make. Autogenerated Makefiles are always inscrutable, and this one is no exception. Fortunately, the autodetected settings are all at the top. Which is good, because if you’re trying to use clang/clang++, you’re going to need to edit those by hand. And don’t forget to add --std=c++11 to CFLAGS otherwise you will not go to space today.

But hey. This is workable. I can script (have scripted) the parts that don’t make sense to me. It won’t fix my lack of design sensibilities (I like metal, black, and sharp corners in every sense of the phrase), but at least the fault isn’t my tools now.