Plans
When we started development towards GTK+ 4, we laid out a plan that said GTK+ 3.22 would be the final, stable branch of GTK+ 3. And we’ve stuck to this for a while.
I has served us reasonably well — GTK+ 3 stopped changing in drastic ways, which was well-received, and we are finally seeing applications moving from GTK+ 2.
Reality
But, GTK+ 4 is taking its time to mature (more on that in another post), and some nice new features (such as font variation support, or Emoji completion) languish unused in master. We also get requests for critical APIs from some of the ported applications.
Therefore, we have decided that it is better to change course and allow a limited amount of new features and API in GTK+ 3.x, by doing a GTK+ 3.24 release in September.
There is now a gtk-3-24 branch in git. GTK+ 3.x maintenance has moved to that branch, and we won’t be doing any further 3.22.x releases.
Highlights
The first release off this new branch is GTK+ 3.23.0, which can be found here:
https://download.gnome.org/sources/gtk+/3.23/gtk+-3.23.0.tar.xz
The highlights of this release include new font chooser features,
- Allow setting OpenType font features
- Show examples for OpenType font features
- Allow selecting OpenType font variations
- Support levels of details for selection
new Emoji features,
- Support a completion popup for Emoji
- Drop Ctrl-Shift-e shortcut
gdk_window_move_to_rect as public API,
and the Wayland backend using anonymous shared memory on FreeBSD.
Numerology
A side-effect of doing one more 3.x cycle is that we will have GTK+ 3.24 to be the final GTK+ 3, which is a pleasant parallel to GTK+ 2.24 being the final GTK+ 2.
Fractional scaling?
> Emoji completion
WAIT WHAT!? Is any info about this available anywhere?
background blur please
Hi,
will this final 3.24 realease be backward compatible with the (old final) 3.22 release?
@ramnasko: Yes; only new API was added, as requested by applications like Inkscape and Firefox. There are new deprecations, to ease porting to GTK4, but they can be disabled. Finally, no theming chages.
@Frederik: Already available in GTK master, but can only be done for 4.0: it cannot be backported to GTK+ 3.24.
@pete: It’s the responsibility of the compositor, not of the toolkit.
Assets and windowing system surface can only use integer scaling; font rendering can already use different DPI values.
> It’s the responsibility of the compositor, not of the toolkit.
Why does Qt provide fractional scaling then?
@Emmanuele Bassi: That’s only a problem with Gtk, other toolkits such as Qt, the Android toolkit, Windows UWP, etc handle fractional assets and window surfaces just fine.
It’s a bad, and broken, design decision of the Gtk team that caused this trouble. And it’s going to cause even more trouble, with Gtk apps that mix Gtk and 3D rendered content, and where on a 1.5x 4K screen they suddenly have to push 6K, half of which the user will never see.
@pete: Qt provides “fractional scaling” in the same way as GTK does: for text, and controls that are sized through their text contents. Fractional scaling for assets and windowing system resources makes no sense: you cannot have a window that is 100.5 pixels by 200.2 pixels — and you cannot have an icon asset that is scaled fractionally without having blurry results.
GNOME allows you to handle fractional scaling with an experimental toggle, as it’s not heavily tested; see: https://www.omgubuntu.co.uk/2017/09/enable-fractional-scaling-gnome-linux
@Janne Koschinski: I’m sorry, but that does not make any sense. macOS, iOS, Windows, Qt, and Android use the same functionality as GTK in terms of scaling: by providing assets scaled to the desired output. The display server can, and will, scale contents if not available, but the results will be blurry because you cannot make up pixels you don’t have.
Thanks for the answers Emmanuele, terse and clear clarifications :)
gtk/language-names.h is missing from the tar.xz.
Yes, it’s a known issue; see: https://gitlab.gnome.org/GNOME/gtk/issues/1173
It’ll be fixed in the next snapshot.