identifying GTK5 features (the ones that require breaking API)
additional GLib/GIO feature work for enabling the two points above
GTK pain points that should be addressed
builder vs blueprint - what is the future here ?
focus handling for subclassing
establishing the “platform team” for project governance of the core GNOME platform
Minutes
GTK Hackfest topic: re-integrating generic functionality from libadwaita
EnumList was merged
ClampLayout was made for list to make them scale on mobile
Breakpoints are complicated, and libadwaita use their internals; they would have to be rewritten for use inside GTK
Stacking breakpoints is also complicated
GTK could do a better job than libadwaita (various hacks would not be necessary)
Minimum size is another complication
Are there other low hanging fruits that we can move from libadwaita to GTK?
Animations?
libadwaita has explicit animations, GTK has CSS transitions/animations, GtkSvg has animations
CSS styling or actual code?
WrapLayout (widget wrapping) could be moved into GTK
Does it support height-for-width/width-for-height geometry?
It should
If we get a new layout mechanism for GTK5, we’ll need to port multiple layout widgets
Building a new layout API would also require a new model to follow—e.g. HTML/CSS/SVG, to get support for percentages
The complication is that the window size is the result of the layout computation in GTK, whereas HTML/SVG have a fixed viewport size
Measurement unit split: measurement in relative units, allocations in pixels
Flow layout: text reflowing with widgets
select/copy/paste over multiple widgets
Tuba has a specific layout that replaces Pango attributes with widgets
Reflect text layout inside the widget tree
Some requests from Tuba
lists and recycling views
Builder factory is somewhat deprecated
Signal factory is messy for custom data
Different row types can be inefficient
GApplication/GtkApplication behaviours discovered during the save/restore session implementation
GTK5 may need to move GtkApplication to composability rather than inheritance
Pain point: focus handling
Some discussion during the 2026 hackfest to switch over to an event controller instead of traversing the widget graph
Some experimentation to make GtkWidgetClass.grab_focus do the right thing by default (self assignment and child traversal), to remove the need to override virtual functions
Still some work to be done
Pain point: XML vs Blueprint for UI definition files
Blueprint is out of tree for convenience/fast iteration
Dependency on introspection data makes it hard to use for GTK itself (UI definitions are needed at library build time, before GIR is available)
Any in-tree format needs to be able to extend support for other libraries
Custom extensions through the Buildable interface
Maybe the solution is a formal intermediate format that is neither XML nor Blueprint
Keep the human writable UI definition format out of GTK
Still needs to be extensible
Still needs to be readable and writable for the Inspector to edit
Platform team discussion
Part of the new technical governance proposal
A group made of existing maintainers of GNOME platform libraries, with regular meetings
Planning for complex features across projects
Acting as a reference point for questions from app developers, designers, binding developers, etc
Regular meetings, with an agenda of issues using a well-defined label on GitLab; triage issues, answer questions, plan for future work, and maintain a record that can go on the release notes at the end of each cycle
The GtkBuilderListItemFactory isn’t really used outside of demos; and it’s also useless if you’re using blueprint-compiler, because it requires parsing a nested XML fragment.
Because once it’s inside GTK, it cannot change, and iterations are going to require major API breaks.
That’s good to know, but you’re likely the only one, as far as we know.
Oh, that’s nice. It’s still a nested parser, but at least it’s usable—and slightly more so than the XML embedded into a CDATA payload.
The main point of the discussion was that, with subparsers and introspection requirements, any human writable format that is also extensible would end up not being usable by GTK itself, so maybe GTK should define a neutral intermediate representation. Another approach would be for GTK to do code generation at build time, instead of embedding UI definitions inside the shared library and then loading them up at run time.
In practice, though, the whole topic of UI definitions in GTK5 is still pretty fuzzy.
I recently started to use Builder factory (with a printf-generated template), because there is much less ceremony than with Signal factory. Especially with unbind.
