I haven’t written about GTK+ development in some time. But now there are some exciting things happening that are worth writing about.
Plans
Back in June, a good number of GTK+ developers came together for a hackfest in Toronto, It was a very productive gathering. One of the topics we discussed there was the (lack of) stability of GTK+ 3 and versioning. We caused a bit of a firestorm by blogging about this right away… so we went back to the drawing board and had another long discussion about the pros and cons of various versioning schemes at GUADEC.
The final, agreed-on plan was published on the GTK+ blog, and you can read it there.
Actions
Fast-forward to today, and we’ve made good progress on putting this plan into place.
GTK+ has been branched for 3.22, and all future GTK+ 3 releases will come from this branch. This is very similar to GTK+ 2, where we have the forever-stable 2.24 branch. We plan to maintain the 3.22 branch for several years, so applications can rely on a stable GTK+ 3.
One activity that you can see in the branch currently is that we are deprecating APIs that will go away in GTK+ 4. Most deprecations have been in place for a while (some even from 3.0!), but some functions have just been forgotten. Marking them as deprecated now will make it easier to port to GTK+ 4 in the future. Keep in mind that deprecations are an optional service – you don’t have to rush to act on them unless you want to port to the next version.
To avoid unnecessary heartburn and build breakage, we’ve switched jhbuild, GNOME continuous and the flatpak runtimes over to using the 3.22 branch before opening the master branch for new development, and did the necessary work to make the two branches parallel-installable.
With all these preparations in place, Benjamin and Timm went to work and did a big round of deprecation cleanup. Altogether, this removed some 80.000 lines of code. Next, we’ve merged Emmanueles GSK work. And there is a lot more work queued up, from modernizing the GDK layer, to redoing input handling, to building with meson.
The current git version of GTK+ calls itself 3.89, and we’re aiming to do a 3.90 release in spring, ideally keeping the usual 6 months cadence.
…and you
We hope that at least some of the core GNOME applications will switch to using 3.90 by next spring, since we need testing and validation. But… currently things are a still a bit rough in master. The GSK port will need some more time to shake out rendering issues and make it as fast as it should be.
Therefore, we recommend that you stick with the 3.22 branch until we do a 3.89.1 release. By that time, the documentation should also have a 3 → 4 migration guide to help you with porting.
If you are eager to get ready for GTK+ 4 now, you can prepare your application by eliminating the deprecations that show up when you build against the latest 3.22 release.
Summary
This is an exciting time for GTK+ ! We will post regular updates as things are landing, but just following the weekly updates on the GTK+ blog should give you a good idea of what is going on.
What will be the “theming situation”? That is, will gtk-3 and gtk-4 apps look and behave the same or will they eventually differ? It sounds like gtk-4 apps will initially be mostly core gnome apps, so it would be sad if they looked and felt different to other apps.
I believe the theming API was declared stable, and is not the focus of development anymore. I’d say, only expect bugfixes and more features going to the theme support from now on.
And no, I don’t think anything will break theme-wise.
Except that we’re removing the deprecated custom style properties, so yes: themes for 4.x will necessarily have to change.
Themes are still going to be parallel installable; the same people who work on Adwaita for GTK+ 3.x also work on Adwaita for GTK+ 4.x — and they are going to try to keep the two themes close to each other, just like they tried for GTK+ 2.x themes.
The overall goal, though, is to ensure that Adwaita is maintainable and allows theme authors to write better CSS; not everything that can be done in 4.x will be available in 3.x, just like not everything that was available in 3.x could be replicated with the 2.x theme internals.
When was the decision to move to meson made, and for what reasons?
@Alex: Meson is probably the best option for us, since it covers most of what we want or need out of a build system: portability; use of existing established technologies like pkg-config, gtk-doc, and introspection; and we’ve begun experimenting and fixing its shortcomings over various projects in GNOME, like GStreamer.
We’ll likely keep autotools for a while, though.
Looking at the high profile GTK-based projects that already use CMake (WebKitGTK, Inkscape, darktable), this feels like huge missed opportunity. Like when pidgin switched from monotone to mercurial, when the rest of the world already realized that git had won. Even Mircosoft will support CMake in the next version of Visual Studio natively.
There are downsides to switching to Meson — like its relative young age, and the lack of tooling integration — that are perfectly fair to bring up, and that will need to be solved while in the process of switching large projects, like GTK+; if the porting process fails, then Meson will need to mature before it’s attempted again.
Having said that, I personally find CMake lacking in a bunch of respects — like its obsession for copy-pasting modules between projects; its inability to rely on pkg-config because of FUD; and custom commands being terrible. I’ve had to deal with CMake breakage in GNOME Continuous, and it’s a pain in the ass of barely manageable proportions. This is something that other people involved in building complex systems based in multiple components have been raising.
Meson provides us with various benefits — mostly, it covers all that CMake provides, in a slightly better way, and gives us support for basic technologies that GNOME modules already use. Additionally, GStreamer and other projects have either already moved to Meson, or are actively in the process of switching to it.
I strongly encourage you to have a look at the Meson talks from Jussi and Nirbheek at GUADEC 2015 and 2016, respectively.