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:
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.)
Fix qt.pro. I think every time I have needed to add the line
QT +=to this file and I don’t know why. Possibly wishing to avoid
trying to parse C++?
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
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
CFLAGSotherwise 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.