# GTK Hackfest 2026 As is a usual occurence, the GTK developers are organising a hackfest for high bandwidth discussions and general planning. **When**: January 28-31, 2026 **Where**: Brussels, Belgium Address: Rue de Stassart 35 ## Topics - SVG status and directions. I'd like to give an overview on what has been done, whats missing, and discuss the future directions (Matthias) - Can we move the icon editor outside of GTK? - What's missing to implement filters fully? - Can we have more CSS integration? Do we want to? - Should we drop the librsvg dependency for 4.22? - MR is https://gitlab.gnome.org/GNOME/gtk/-/merge_requests/9333 DONE - from Benjamin: is https://webidl.spec.whatwg.org/ relevant for dom api / introspection compatible ? - Icons in general: We still need a better solution to - allow the new svg features to be used - avoid all the icontheme issues - give platform libraries a say in this - MR is https://gitlab.gnome.org/GNOME/gtk/-/merge_requests/9046 - Do we want to bump our language/toolchain requirements for GTK (and GLib)? - C11 atomics, stdint, bool - threading - autoptr? - Prefer non-g types harder ? I've started to use size_t instead of gsize - Renderer status update (Matthias/Benjamin) - Unstable APIs ? (Matthias) - Do we want an installed gtk-unstable.h ? - It would contain apis that we aren't ready yet to freeze, but that are needed/useful in tools - It can avoid static linking e.g. the icon editor - Impact on language bindings? - How to keep up with WAI-ARIA - Web API changes, impact on the type system - Backward compat or stringly-typed attributes? - Windows situation - ci has recovered, thanks to some work by lazka - I've donated some money to the cause - The code needs more investment to be worthwhile - Android - glib integration - filesystem (re-)organization requested by @larma - complex IME handling - cross G-I generation (if @xclaesse is there) - libappstream - AccessKit? - General project maintenance - Growing MR backlog (up to 350+) - Growing issue backlog (up to 1800+) - CI review - what OS'es do we want to have build for - what is missing? - what is unnecessary? - GTK 3 is getting very old - Platforms: risc-v ? do we have ci? do we want to support it? - gdk-pixbuf - Done at the hackfest: https://gitlab.gnome.org/GNOME/gdk-pixbuf/-/merge_requests/255 - time to archive the loaders? - Filter API for GtkImage? - Add your topic here ## Attendees | Name | Area | Arrives | Leaves | |------|------|---------|--------| | Matthias Clasen| all over, but currently SVG | 28/01 | 01/02 | | Carlos Garnacho | Input, mostly | tbd | tbd | | Emmanuele Bassi | Accessibility, GLib, bindings | 28/01 @ 12:05 | 03/02 @ 13:52 | | Marco Trevisan | GLib, bindings | 27/01 @ 14.30ish | 02/02 | | Alessandro Astone | | 27/01 @ 14:00ish | 02/02 | | Florian Leander Singer | Android, a bit SVG | 29/01 @ 12:00 ish | 01/02 @ 18:00 ## Notes First day happenings: #### Early code gdk-pixbuf 2.44.5 was released with glycin support for xpm+xbm #### Topic: Unstable api Concern about abi checkers. Suggestion from Emmanuele: Do a libgtk-unstable to go along with gtk-unstable.h. We'd want this to have language bindings as well, and probably use a separate namespace, like gtkx Matthias will do some experiments with that #### Topic: New glib things Emmanuele is still working on type system renovations that are inspired by C++/rust: move reference counting out of objects to shared pointers. For next cycle, we aim to do the C11 requirement in glib, including atomics, stdint and stdbool. Using non-g types is totally fine and should be encouraged. We also had a discussion around autoptr, defer and whether we can drop msvc for gtk5. The reason for msvc used to be debuginfo, but other toolchains can build pdb stuff nowadays #### Topic: threading We looked at the various things where gtk can benefit from threading: - texture loading - svg loading - rendering (not currently done) - layout (much more difficult) No need for libdex in gtk #### Topic: a11y We are a bit uncertain about the status of AccessKit. Even if we assume AccessKit to stay alive, we need to find somebody to keep the gtk backend for it updated. So we probably need to keep at-spi working. There is some work left to make version negotiation work there. The fact that aria keeps changing is a bit of a hassle, e.g. changing value types from a boolean to an enum would require breaking our api. We also talked about the collection interface and the fact that libreoffice wants to use it. It is basically 'xpath for a11y', not something we are enthusiastic about. Emmanuele suggested that we may provide it just for lo without implementing or using it otherwise, like GtkAtSpiSocket for WebKitGTK. Carlos has a pointer query api to land in mutter, that should be the last thing missing for orca in mutter. #### Topic: dropdowns Emmanuele found that we wants a search-expression and a search-filter. Should not be hard to add https://gitlab.gnome.org/GNOME/gtk/-/issues/8003 https://gitlab.gnome.org/GNOME/gtk/-/issues/8004 #### Topic: state saving Adrian presented his concerns with the state saving api, and we agreed to remove the API for 4.22. We merged his MR to do so. Day two happenings #### Topic: releases GTK 4.21.5 was released #### Topic: project maintenance Emmanuele suggestions: better labelling for MRs (platform, backports, needs rebase, newcomers). Carlos suggests to use mutters input replay infrastructure for tests. #### Topic: risc-v We probably don't want it, until the situation improves. #### Topic: gtk3 We agreed that we want to limit bug-fixing to crash and build fixes. #### Topic: gdk-pixbuf Decision: Put more of the minor formats to gdk-pixbuf-extra (keep png, jpeg), clean up gdk-pixbuf-extra, and move it to the gnome namespace. We also talked about maybe getting rid of libtiff from gtk, since it drags in libstdc++ and libwebp. Day three happenings #### Topic: libadwaita <> gtk Emmanuele and Matthias looked over the libadwaita api and spotted a few candidates for moving to gtk: - ClampLayout - Breakpoint plumbing - Enum list model Looking at the other direction, we discussed having an extension point for plugging other color chooser dialogs into the GtkColorDialog api (extension point, since this does not need a portal). See https://gitlab.gnome.org/GNOME/gtk/-/merge_requests/9419