This will be a longer post summarizing some of the discussions and decisions at the recent GTK+ hackfest in London.

I’ve just released GTK+ 3.90, as a milestone on our way towards GTK+ 4. This post should explain not just what is or isn’t in that release, but also where we are on the journey towards GTK+ 4, and what changes are still in the pipeline.

The reason for doing a 3.90 release now and not just another 3.89.x milestone is that we want to encourage experimental ports of some GTK+ 3 applications at this point, to gather feedback.

If you want to do this for your application, you should be aware that we are not promising more than 6 month API stability yet. There are still a number of unfinished transitions and fundamental changes (such as dropping subwindows, or moving container APIs to GtkWidget) that can and will affect application APIs before GTK+ 4.

I am willing to do a few 3.90.x snapshots if there is interest, but you should also be prepared to keep your application building against GTK+ 3, since 3.90 may not be widely available in distributions.

Hackfest happenings

We had a 3 productive days in London last week. The hackfest was a bit different from previous GTK+ get-togethers since we had a bigger and more diverse audience, which means that we had less down-in-the-details discussion about GTK+ internals.

Instead, some of us spent time discussion portals, Flatpak, build services and other things – but I will focus on the GTK+ parts in this post.

The GTK+ discussion was sometimes a bit higher-level, with topics like graphics pipelines and how we use them in GSK, or constraints and how they can fit into the GTK+ layout machinery.

I’ve personally enjoyed this change of pace quite a bit, and hope we can repeat this style of event in the future.

The details: GSK

We spent a while reviewing how far we have come with rebasing the GTK+ rendering onto GSK (and thus, GL / Vulkan). I won’t go into excessive details here, but we have both a Vulkan and a GL renderer for GSK.

The Vulkan renderer has shader implementations for many of the performance-relevant elements of CSS that make up GTK+ widgets. One major omission is that we still don’t handle text natively and fall back to cairo rendering and texture upload for it. We decided to look at cogl-pango and lift the necessary texture atlas and pango renderer from there, as far as possible.

The GL renderer is much less complete, since Benjamin has focused on implementing things on the Vulkan side at first. The plan here is to finish the Vulkan side first and then port things over to GL. One difference between the backends that we discussed at some length is that while changing pipelines is cheap with Vulkan, that may not be the case on the GL side, so we may need an optimizing pass over the render node tree to minimize state changes.

The details: constraints

Emmanuele gave a demo of Emeus, which is his implementation of constraints-based layout for GTK+. This demo left me feeling quite positive – everybody seems to be moving in the direction of constraints-based layout.

Emeus also supports Apple’s shorthand notation for constraints, so it should be familiar to many people who don’t have experience with GTK+’s nested boxes model. If we can integrate this in time for GTK+ 4, it could make a real difference for how GTK+ applications are designed and implemented.

In the discussion after the demo, we touched on questions of how we could possibly reimplement existing GTK+ containers in terms of constraints, and how we can take even more advantage of constraints by making Emeus composable.

Of course, there are questions of how far this approach will scale – could you put all of gtk-widget-factory into a single system of constraints and solve it while resizing the window ? We will find out…

The details: input

One of the reasons why we are moving to GL-based rendering is that we want to enable more pervasive animations in many places. One example that we’ve discussed is animating the showing and hiding of list or grid elements in a filtered list box or flow box. Doing this smoothly at 60 frames per second requires that we can move and transform elements without causing full relayouts, which in turn means that we to separate positions from sizes, which is only practical in a world without subwindows.

Therefore, one of the milestones on our journey towards GTK+ 4 is to move event handling away from using subwindows for routing input events to their target. Once we have taken this step, it will also be possible to take transformations into account.

Carlos just posted a branch that is taking the first steps in this direction.

The details: children, nodes and gadgets

I’ve already talked about Emeus and constraints, so I won’t repeat that here. But there are some other changes in the way GTK+ widgets work that are worth mentioning here.

We are moving away from GtkContainer as the parent class for container. Instead we now allow any widget to have children. The APIs for this are more DOM-like than GtkContainer: gtk_widget_get_first_child, gtk_widget_get_last_child, gtk_widget_get_next_sibling, gtk_widget_get_prev_sibling.

In GTK+ 3.20 and afterwards, we introduced gadgets as internal construct that allowed us to clean up our widget’s adherence to the CSS box model. This was always meant as a stop-gap solution for pre-existing widgets that were just too complicated to fit the CSS box model well. Now that any widget can have children, we have begun to replace some of these gadgets with regular widgets.

For example, GtkSwitch now has three child widgets: the slider and two labels.

Summary

We’ve had a successful hackfest and GTK+ 4 development is on track, with 3.90 as a visible milestone. Try it out!