Notes

Schedule

• Designer
• Shortcuts / Keyboard input
• Accessibility
• Text Rendering
• GL Renderer
• Animation
• Layout
• Effects
• Reusable rows
• Build system
• Tiling states
• Threaded rendering
• Builder ui file format

Build system status

• glib has both
• gtk master has both
• pango is done
• gdk-pixbuf almost done

What we need:

• meson best practice documentation
• standardized option names

Designer

• Christians ideas:
  • constraint-based layout + states + animation
  • moving from designing widgets to story-boarding
  • define transitions and animations
• Layout plans:
  • make a per-toplevel constraint solver and have all widgets add their constraints there
• States:
  • automatic states:
    • portait vs landscape
    • small vs large
  • custom states
  • some discussion about what level of granularity states should be at
• File format:

  • consider moving away from GtkBuildable

  • use GVariant instead ?
• Plan:
  • first land emeus
  • then look at adding states
  • do a ui designer for constraints
  • make it a requirement that new widgets work in the designer

Shortcuts / Input

• Christian describes his shortcuts engine work
• It is close to an event controller
• Plan:
  • Do capture-bubble for key events
  • Add a shortcut event controller (based on Christians work)

  • Replace GtkBindings by event controllers

Accessibility

• Benjamin describes the horror of the current a11y stack
• We need to start over
• Proposal: an a11y hackfest
• An idea: make speech work on OS X using their native support, and then abstract it
• Concern: if we move away from the current stack, all the other players break: qt, browsers, libreoffice
• Writing a plan for what needs fixing and taking it to the board is attractive
• Should atk be just aria?
• Invent another crack layer to make current stuff work somewhat in flatpak ?

Text rendering

• Will be discussed in detail tomorrow in the text rendering bofs
• We need text render nodes and glyph texture caches
• Christian Kellner is working on some of this

GL renderer

• We need to port the vulkan work back to GL
• Questions: do we want to allow custom effects with uploading glsl ?
  • probably not, we should stick to predefined, parametrisized effects
• Do we want our own shader compiler ?
  • No
• A problem still is how to combine the effects into a single program
• We need more than one GL renderer: legacy, and GLES need to be separate
• We need some flashy effects showing off GL
  • stack transitions
  • revealer transitions

Lunch break

Reusable rows

• We need a way to give GtkListBox full control of child lifecycle

• We need some hooks in the size allocation machinery to only keep visible children alive
• A prototype exists in libdazzle

Popovers / Subsurfaces / Toplevels

• Question: do we want to move popover in the widget hierarchy ?
• Question: what kind of window do we create for it ?

• Question: how do we fix the ifdef mess - make a GdkWindowSubsurface that somehow does the right thing

Release roadmap stuff

• Keep GTK3 stable
• Be flexible about minor API additions
• Encourage people to use their own widgets if they need them
• GTK4 roadmap

Animation api

• ClutterAnimation is fine as a high-level api

• Need to batch all the animation advancing and changes and invalidate everything at once
• Add a new frame clock phase for this - need to figure out if this is necessary
• Make invalidations fast, first
• Consensus seems to be to not have this as a gtk4 blocker, but we should the plumbing in place

Effects

• Effects will be implemented as new render node types as-needed
• These render nodes will be used in widget snapshot functions

• Blur would be a good example to use for an effect. Apply it from GtkOverview for an overlayed child