1. Notes from the Hackfest

1.1. Day 2

1.1.1. Gestures / Multitouch

• Lots of time spent reviewing and comparing multitouch and gesture apis on other systems: Qt, OS X, webkit, utouch
  • TouchBegin/Update/End events are pretty universal, there are different approaches to higher-level parts
  • Qt has client-side event controllers
  • utouch wants to do gesture recognition system-wide to ensure uniform behavior and coordinate with e.g. the wm
  • there is a complicated touch grab / ownership protocol in XI2.2 to make this possible without excessive delays
  • on OS X/iOS, gestures can be cancelled externally (incoming phone call...)
• We went over the various parts of Carlos multitouch branch again in detail
  • touch events were uncontroversial, just want to have a cancel
  • general impression about clustering and multitouch events was to keep this out of GDK and do it in GTK+ without event api

  • kinetic scrolling: the event capture/replay was very unpopular as an api, might want to keep the hack in GtkScrolledWindow

  • capture-bubble event propagation: mainly needed for kinetic scrolling with 'uncooperative' child widgets
  • press-and-hold: general impression was that this should not be ad-hoc api, but treated 'as a gesture'
  • gesture interpreter: recognizes 'stroke gestures', which are different from 'natural' gestures like pinch, swipe or hold.
  • smooth scrolling: was discussed briefly, and found to be uncontroversial
• After lots of discussion, it became clear that we want defer the higher level multitouch and gesture parts of this work until we have an event controller framework
• Some of the lower level pieces (touch events, smooth scrolling) were accepted for 3.4
• capture-bubble had a somewhat inconclusive discussion. Later discussion seemed to lean toward including it without the hold-and-replay api parts, since we really want kinetic scrolling

1.2. Day 3

1.2.1. Gtk/Clutter

• GtkWidget has-a ClutterActor

  • GtkWidget is a model object that deals with state, and delegates rendering to ClutterActor

  • event handling is deferred to delegate objects (EventController)

• do we bump API or bump dependencies?
• we have built up a bunch of deprecations and potential deprecations already
  • legacy layout manager properties

  • GtkMenu, GtkMenuShell, GtkMenuItem

  • styling code in GtkComboBox

  • child/input windows
  • native windows
• if we add Clutter/GL as a dependency how do we handle:

  • GtkPlug/Socket

  • GL rendering

1.2.2. Design team discussion

• custom widgets vs theming: has always been problematic, will be getting better when we do the boxes transition
• problems with highly precise mockups
  • implementing pixel-perfect things does not quite work
  • Allan thinks it is fine to not be pixel perfect and just take the mockups for general direction
• need to test applications against a defined set of themes
• jon says: toolkit needs a default theme
• which themes do we care about:
  • adwaita / adwaita dark
  • a11y themes
  • win32 / osx themes (?)
• awaita will become the default theme medium term, Raleigh is just for debugging
• problems with overriding themes from applications: no good solution atm
• prototyping new design patterns:
  • currently a lot of iteration and prototyping happens in new applications: documents, contacts, boxes
  • one idea is to extract and document 'official' style classes once these patterns settle down, so they can be reused
• form factors, etc:
  • designers view is that we're leaving the era of mouse-only interaction
  • we will have to support available hardware, including various touch-enabled devices
  • it will be necessary to keep precision pointing devices working
  • concern: subpar experience on both desktops and tablets
• problematic areas from designers view: notebooks, scolling, printing
• broken widgets: spinbutton (now fixed!), color chooser (now fixed!)

1.3. Day 4

1.3.1. Roadmap

for clutter:

• GNOME 3.4 will have clutter 1.10: further deprecations, smooth scrolling, touch events
• there will be a clutter 1.12 with the remaining apocalypses (hopefully in time for 3.6)
• after that, clutter 1.90 leading to 2.0, expected timeframe: 9-12 months

for GTK+:

• 3.4: touch events, smooth scrolling and kinetic scrolling
• start working on event controllers in a branch
  • a bit of a research project, not entirely clear how this will look in detail
  • may be ready to merge in 3.6 - perhaps just internal use first, api later
• render objects will be implemented after that
  • will first be implemented using cairo, with an api identical to the clutter actor api
• porting to clutter will happen on a 3.90 branch
• timeframes
  • 3.4: 2 months
  • 3.6: 8 months
  • 3.90: 12 months
  • 4.0: 18-24 months

1.3.2. Miscellaneous roadmap-related discussion

• The clutter (and thus GL) dependency seems to leave us no choice but to go for a 4.0 bump
• Chase was asking for having event controllers being developed on master to make it easier to get this into ppas
  • Seems unfeasible, we can't do early prototyping directly in master
  • Matthias offered that we will rebase the branch onto master regularly and keep it in snapshottable state
  • We may even do an experimental tarball off the branch once it is complete enough
• do we want to deprecate gdk threads ?
  • yes, deprecate post 3.4, remove in 4.0
• move icon theme lookup to gio ?
  • unclear, might fit better into a successor of gdk-pixbuf
  • but no such successor on the horizon
  • gdk-pixbuf is only minimally maintained

• whats missing from GtkOsxApplication ? (private discussion between Ryan and Matthias)

  • relocatability (should look at adding those apis in GLib)

  • 'requires attention' - can easily be implemented on X using urgency hints, but we should have a GtkApplicationWindow api

1.3.3. Patch review

• GProperty: remaining questions have been cleared between Ryan and Emmanuele have been cleared, new patches will be merged before 2.32
• signal optimizations: Alex has been reviewing the patches, will merge some version of them this week

• Ryan and Matthias agreed on simplifying the GtkApplication session support, by adding a g_application_quit() function and dropping the GtkApplication::quit signal and the request-shutdown api