Some of the core GTK developers recently got together for a few days to do some focused work and talk about current and future plans.
It is difficult to summarize three days of discussions in a blog post, but here are some of the highlights.
Icon themes
The GtkIconTheme code has been with us for a long time. It implements the icon theme spec, and comes from an era when we were shipping big sets of icons with the desktop and themes were expected to switch them out. That is not really how icons are made or used today.
We need a better solution for the workflow from a designer making icons a set of icons in a sheet to the developer copying individual icons into their app.
Inside GTK, this will need some form of “asset manager” to maintain the mapping from icon name to image / file / resource.
Languages
While we can’t get away from providing a C interface with gobject-introspection metadata for all our language bindings, it could be nice to use a more expressive language and a more powerful compiler than C has to offer.
Of course we can’t and won’t rewrite all of GTK in a different language. It would be nice to experiment with replacing smaller parts. Allowing new code to be written in different languages would also potentially bring in new contributors.
Input
We discussed the scroll speed question, and decided to write up an explanatory comment in the issue about what we consider the right solution:
- treat wheel and touchpad scrolling separately
- inject configuration from the control-center/compositor into libinput
- gtk gets it via events
The other big input question we talked about is ‘asynchronous event handling’ and its problems. The two main cases where this comes up are webkit, with its ui<>web process communication, and IBus. In both cases, we think that there is no actual interest in reinjecting unhandled events into the GTK capture/bubble propagation. Instead, such leftover event should just be handled ‘locally’ (in the IBus case, adding/removing characters to the entry, or moving the cursor).
Platform libraries
With GTK4, we’ve made the intentional change to move away from having everything in GTK itself, and instead introduced the idea of ‘platform libraries’ like libadwaita to carry the more platform-specific widgetry.
Overall, we are happy with how this has turned out, and we would like to continue with this approach. There is maybe room for moving some things that are more plumbing than widgetry back into GTK itself.
GTK5 ?
We need to open a .90 branch to do things that would break the APIs that we have deprecated now (like the file chooser, and more general the chooser dialog/widget split). Some of us have been itching to start on that work. But there’s also still a lot of work to be done in 4.x (GtkListView fixes, for example).
With an eye towards the color management work that is planned to land in 4.12, the suggestion is to open a 4.90 development branch after 4.12. That would put it towards the end of this year, and 3 years after the 4.0 release, which seems reasonable.
The End
On the last day, we had the pleasure of hosting both the documentation and the tracker teams at our place.
Three hackfests in a room!
We’d like to thank the GNOME foundation for supporting our meeting. ❤️