Platform Planning Call minutes for 2026-05-29

Teams Platform
,
1

Agenda

Minutes

  • Layout

    • Support for CSS max width/height is relatively easy in the parser
    • How do we integrate with the layout implementation
    • Are they mandatory?
    • How do CSS max size interact with min size
    • Enforcement inside GtkWidget
    • How do we take it into account when measuring a widget?
    • We discussed something like this for GtkLabel size computation (max width chars)
      • Label behaviour is not mandatory in 4.x, but it started off as mandatory; it was removed because people could not change it and it was unexpected
    • Label/text interactions between max-width-chars/max-width
    • Original case: cells of known max size/aspect ratio, used to limit the maximum size
    • Needs additional reftest cases (especially with ListView)

  • UCD for keys and navigation

    • motivation: adding semantic grouping for activation and navigation
    • should live near the key definitions
    • should we allow applications to define their own grouping?
    • should we add trigger objects for keys?
    • GTK hackfest topic: a navigation event controller would remove some of the direct key handling, and integrate with the trigger API
    • potential for conflicts between low level controllers set up by applications, and high level ones provided by GTK
      • maybe a separate hierarchy for high level controllers

  • Scrolling

    • original motivation: have different scrolling regions within the same scrollable widget
    • scrolledwindow is very, very complex (lots of event controllers, lots of toggles/policies)
    • If we invent a new interface and a new scrolling widget, can it be done within GTK4 or do we need GTK5?
    • What happens with widgets that implement GtkScrollable today?
      • Custom widgets that implement a scrolling area without using GtkScrolledWindow
    • Add a private interface/private widget for internal use?
    • Add multiple scrolling container widgets instead of putting everything into a single one
      • Keeps complexity manageable
    • Out of tree experiments are kind of hacky
    • Interaction with input: rotation/scale transformations
    • Maybe isolate some core functionality into a base object?
    • More experiments in tree
    • Possible overlaps with existing API:
      • Everybody hates GtkAdjustment
      • No clear separation of roles, various layering violations
      • Multiple components try to set the values
    • Possible approach inside gtk4: new GtkScrollArea to live next to GtkScrolledWindow
    • Set up a call for designing Scrolling: suggestion: In a week
      • 2026-06-05 13:00 UTC

  • AccessKit/Newton

    • Unknown state upstream; some work is still happening
    • AccessKit works on macOS/Windows (we got bug reports and merge requests to fix issues there)
    • Some missing functionality for AT-SPI; our current backend has the most coverage
    • Needs some proper investigation on what’s missing and who would be willing to work on it
      • Possible idea for a round of funding

  • Pango

    • Maybe “dissolve” it into GTK5
    • Discussion may happen at GUADEC 2026
    • Backward compatibility in the API and assumptions on the environment, like font loading
    • “Pango 2” branch breaks backward compatibility, but needs more maintenance resources
    • Lack of users driving features outside of GTK
    • Text rendering
    • Text stack is currently driven by HarfBuzz; the only thing that HB does not do is paragraph layout, which is what we need in GTK
    • Switching to “Pango 2” internally to GTK would require an API break in GTK itself because of the Pango types in the API
    • Next to Pango the plan is to phase-put Cairo, as well.