Today, we released GTK+ 3.94.0. Again, it has been a while since the last release, so it is worth summarizing whats new in this release. There is really too much here to cover it all, so this post will only highlight the most important changes.
This release is another milestone on our way towards GTK+ 4. And while there are still some unfinished things, this release is much closer to we hope to achieve with GTK+ 4.
GSK
The Broadway backend now has a GskRenderer, so the future for Broadway looks much better.
We introduced a new type of render node, GskOffsetNode, which is a simplified GskTransformNode and takes over the job of translating content as we move up and down the render node tree. With this change, we are now able to cache render nodes for widgets over multiple frames, and reposition them if necessary.
We also introduced GskDebugNodes, which take over node names, and let us simplify some of the GTK+ apis for creating render nodes.
When falling back to cairo for rendering, we now use recording surfaces instead of image surfaces, so we can replay the rendering at a different scale.
An important new operation is gsk_render_node_diff to compare two render node trees (see below for more on this).
GDK
Following the general trend of aligning the GDK apis with Wayland instead of X, GdkWindow was renamed to GdkSurface.
The GdkTexture api has been refined, with new GdkMemoryTexture and GdkGLTexture subclasses, and a powerful new abstraction, GdkPaintable, has been introduced.
A GdkPaintable represents an object that can be painted anywhere at any size without requiring any sort of layout. This is inspired by similar concepts elsewhere, such as ClutterContent, HTML/CSS Paint Sources or SVG Paint Servers. To show off the power of this concept, a few new demos have been added in gtk4-demo:
The DND code continues to see major refactorings. It now uses the same content-provider infrastructure that was introduced in 3.93 for clipboard handling, and it has separate objects for the source and target side of a DND operation. More changes will be coming here.
GTK
widgets
GTK+ has gained support for showing videos, with the GtkVideo and GtkMediaControls widgets, and there is also a new GtkPicture widget to split off image viewing from GtkImage (which is really about icons).
GtkFontChooser allows tweaking OpenType features and font variations, and Ctrl-Shift-e for color Emoji input has been replaced with completion that can be enabled with the GtkEntry::enable-emoji-completion property.
Input
The event-specific signals in GtkWidget continue to disappear. At this point only ::event is left, but it will go away too. Instead, we are using event controllers, and several new ones have been added to cover all needed events:
- GtkEventControllerMotion
- GtkEventControllerKey
- GtkGestureStylus
To make this transition easier, it is now possible to create event controllers in ui files.
Wayland has its own platform input method, based on the Wayland text protocol.
Drawing
The ::draw signal has been removed, all widgets have to implement ::snapshot. They can now create their own GtkSnapshot instances for intermediate rendering. Clipping is no longer applied on the GTK+ level – widgets are free to draw outside their allocation, if that is what is required.
Widget invalidation has been changed, it now works by discarding the cached render nodes of invalidated widgets, and recreating the missing parts of the render node tree.
For finding the region that needs to be redrawn, GTK+ diffs the render node trees of the previous and the current frame, and applies some heuristics to keep the number of rectangles from growing too large.
The GTK+ inspector lets you track invalidations, which you can see in action here:
Other changeS
GTK+ no longer supports generic loadable modules. Input methods, print backends and media backends have been converted to GIOModules and extension points.
The platform im modules (i.e. the Windows, Wayland, Broadway im contexts) are always included and will be enabled by default on their platform.
The Vulkan support in GDK can now use a particular device that is specified by the GDK_VULKAN_DEVICE environment variable. Use GDK_VULKAN_DEVICE=list to see all availble devices.
Try it out
With GTK+ 3.94.0, it should be possible to start porting applications. The documentation has an initial porting guide.
Thankyou so much for the broadway work!
This does not work for me at all. When I stop moving the mouse in “slow scroll” mode, it stops the scrolling, no matter where my mouse is.
Is this a bug? I’m running gtk3-3.94 and I can reproduce this with most gtk3 applications including nautilus and gtk3-demo.
@Susan: GTK+ 3.94 is not GTK+ 3 — it’s the development branch for GTK+ 4.0. I’m also not sure what you’re testing; are you referring to this other article?
“GTK+ no longer supports generic loadable modules”.
So, this mean to me: If you don’t like how gtk is doing something, you can not modify it anymore.
That’s will be sad and will make gtk unusable to me.
In fact, if i don’t like CSD, for example, i can not use a module like Gtk3-nocsd because it will have no way to modify (hacks) the gtk internally.
Another thing will be that for example, the developer of an application will need to export by himself the menubar, or the appmenu. The result will be that some applications will export the menubar, others will export the appmenu and others will not export anything. In my opinion this will make the linux desktop a Frankenstein, with one application working in one way and another in another.
The shell developers will have not chance to apply a procedure to make more uniforms the applications in his desktops and they will be limited to create or port concepts from other places, like was the case of Unity desktop in a lot of aspects. This will make all Gtk linux desktops more and more plastics and lacking of innovative concepts, becasue they will need to acept the upstream conceibed gtk features, or they will needd to avoid the usage of gtk in favor of other toolkits with more configurables options.
Also, some application developers will prefer to stay in an older version of gtk, to keep compatibility with a feature that was supported thanks to a general gtk module that now will have not way to be loaded. This fact will stoping the normal evolution of that application to a new gtk version that without any doubt will have a lot of improvements.
You tried very hard to read this in the most negative way you possibly could.