What’s new in GTK, winter 2025 edition

Community
1

We just had a GTK hackfest at FOSDEM. A good time for an update on whats new and exciting in GTK, with an eye towards 4.18.

GTK hackfest 2025Requirements

You can no longer call gdk_display_get_default() or gdk_display_open() before gtk_init(). This was causing problems due to incomplete initialization, so we made it fail with a (hopefully clear) error message. If you are affected by this, the usual fix is to just call gtk_init() as early as possible.

On Windows, we have a hard requirement on Windows 10 now. All older versions are long unsupported, and having to deal with a maze of ifdefs and unavailable APIs makes development harder than it should be. Dropping support for very old versions also simplifies the code down the stack, in Pango and GLib.

The same idea applies to macOS, where we now require macOS 10.15.

Spring cleaning

The old GL renderer has been removed. This may be unwelcome news for people stuck on very old drivers and hardware. But we will continue to make the new renderers work as well as possible on the hardware that they can support.

The X11 and Broadway backends have been deprecated, as a clear signal that we intend to remove them in the GTK 5. In the meantime, they continue to be available. We have also deprecated GtkShortcutsWindow, since it needs a new design. The replacement will appear in libadwaita, hopefully next cycle.

It is worth reminding everybody that there is no need to act on deprecations until you are actively porting your app to the next major version of GTK, which is not on the horizon yet.

Incremental improvements

Widget layout and size allocation has received quite a bit of attention this cycle, with the goal of improving performance (by avoiding binary search as much as possible) and correctness. Nevertheless, these changes have some potential for breakage, so if you see wrong or suboptimal layouts in applications, please let us know.

GTK has had difficulties for a while getting its pointer sizes right with fractional scaling on Wayland, but this should all be solved in GTK 4.18. No more huge pointers. Fixing this also required changes on the mutter side.

New beginnings

Accessibility in GTK 4.18 is taking a major step forward, with the new AccessKit backend, which gives us accessibility on  Windows and macOS, for the very first time. The at-spi backend is still the default on Linux, and has seen a number of improvements as well.

And, maybe the biggest news: We have an Android backend now. It is still experimental, so you should expect some rough edges and loose ends. For example, there is no GL renderer support yet. But it is exciting that you can just try gtk4-demo on your phone now, and have it mostly work.

Enjoy!

This is a companion discussion topic for the original entry at https://blog.gtk.org/2025/02/01/whats-new-in-gtk-winter-2025-edition/
7 Likes
2

Love to see the progress made! I’m really happy for the android backend and can’t wait to test it out

3

Nice work!

Why can’t the GL renderer stay?
Many older hardware will not be able to run GTK applications.
Is there any maintenance needed for this older renderer or why does it have to be removed?

Is the cairo renderer still available in this new update?

4

Can you repair the Android link? it’s offline

5

The old GL renderer has been removed because it is unmaintained, and it does not work for all the functionality required by GTK; it was still in tree while the new renderer was being debugged, but it was always slated for removal. Code is not without cost.

6

Will the cairo renderer stay?
I hope yes, because it’s usefull for very old PCs.

7

There are currently no plans to remove the Cairo renderer, but be mindful that it’s a fallback renderer. If you end up using Cairo, you might as well use GL software rendering in Mesa, and get better results.

8

But for Windows Cairo is the only software rendering possible? Is that correct?

9

No: GTK on Windows uses Vulkan or OpenGL.

10

I have an older PC too and I can explictly choose cairo in GSK_RENDERER while vulkan and opengl don’t work (strange colors) on the old GPU of that PC.

But now you’re saying cairo can NOT be used on windows?
How do you explain then it works if setting GSK_RENDERER to Cairo while it displays strange colors in Vulkan or OpenGL (not usable)

11

Where did I say that? I said that Windows uses Vulkan or GL. You can use the Cairo renderer, but it’s an explicit fallback that does not cover all features that GTK provides, and there’s no plan to make that happen, because Cairo is a 2D rendering library, and GTK is a toolkit that allows 3D rendering.

I’m sorry, but we’re not writing GTK in 2025 to cater to hardware so old that it cannot run modern OpenGL, or with broken drivers.

1 Like
12

Ok, sorry I had understand it wrong!
The way it works is perfect and I use Cairo on very old PCs :slight_smile:

13

I’ve been using both: DrawingArea with Cairo for 2D, GLArea for 3D. There’s a quite useful functionality that present in DrawingArea with Cairo(+Pango) functions to work in 2D, and lack of them in GlArea with epoxy bindings. That would be nice to have both options.

p.s. clicking on https://gitlab.gnome.org/GNOME/gtk/-/jobs/4707329/artifacts/browse/apks/org.gtk.Demo4/ leads to a “Page not found”