The GTK+ team had a full day planning session during the BoF days at Guadec, and we had a full room, including representatives from several downstreams, not just GNOME.
We had a pretty packed agenda, too.
GTK+ 3
We started out by reviewing the GTK+ 3 plans that we’ve outlined earlier.
In addition to what was mentioned there, we also plan to backport the new event controllers, to make porting to GTK+ 4 easier. We will also add meson build support to help with Windows builds.
The 3.24 releases will effectively be a continuation of the 3.22 branch and should be entirely safe to put out as stable updates in distributions.
We plan to release GTK+ 3.24.0 in time for GNOME 3.30.
GTK+ 4 leftovers
The bulk of the day was taken up by GTK+ 4 discussion. We’ve reviewed the list of leftover tasks on the roadmap:
- Finish DND: Gestures on the GTK+ level, local shortcuts
- Introduce GtkToplevel and cleanly support popovers
- Add transformations
- Create a shortcuts event controller to replace key bindings
- Port GtkTextView to render nodes
- Profile the cairo backend, make sure its performance is on par with GTK+ 3
- Port various dependent libraries:
- vte
- webkit
- libchamplain
- gtk-vnc
- gtk-spice
Most of these tasks have names next to them, but if you want to help with any of these tasks, by all means, contact us!
Noticeably absent from this list are a few things that were on the roadmap before:
- Constraint-based layout (emeus)
- Shader compiler and application provided shaders
- Designer support
All of these can still happen if merge requests appear, but we don’t think that we should block on them. They can be developed externally to GTK+ 4, and become GTK+ 5 material.
GTK+ backends
We spent some time evaluating the state of GDK backends in GTK+ master.
The Windows backend is in OK shape. We have several people who help with maintenance and feature development for it, meson makes building it a lot easier, and we have ci for it.
The Quartz backend is in a much worse state. It has not been kept in buildable shape, nobody is providing fixes or feature development for it, and we don’t have ci. We had a macbook offered that could be used for ci, and it was suggested that we could use travis ci for the OS X.
GTK+ timeline
We spent a long time on this, and did not reach a 100% consensus, but it seems realistic to aim for a GTK+ 4 release in spring of 2019, if we keep making good progress on the outstanding leftovers.
When we release GTK+ 3.96, we will also announce a date for GTK+ 4.0. We hope to be able commit to release before GNOME 3.32, so GNOME application developers can switch their master branches to GTK+ 4 without worrying about whether that will disrupt other development for 3.32.
Application porting
We really want feedback from application ports at this point. But we are in a bit of a difficult position, since we can’t plausibly claim to be done with major API work until the GtkToplevel and shortcuts controller work is done.
Our recommendation to app authors at this point is:
- If you are a bit adventurous, do a port to 3.94 on a branch. It should be possible to keep it working without too much work during the remainder of GTK+ 4 development.
- If you are not quite as adventurous, wait until 3.24 is released, use it to prepare your port, and port to GTK+ 3.96.
- Either way, please make your port available to users for testing, either as a regular release, or as a Flatpak with a bundled GTK+.
GLib diversion
In the afternoon, we spent a while talking about GLib. We went over a laundry list of larger and smaller items. Notable highlights: GProperty may happen for 2.60 and we may be able to use g_autoptr soon.
Other ideas
We discussed a great number of other things that we could and should do.
For example, it was suggested (and generally agreed to) that we should merge gsk into gdk, since it is small and the internals are somewhat intertwined. It was also suggested to create subdirectories in gtk/, for example for the css machinery.