Notes from the Hackfest

Day 2

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

Day 3

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

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!)

Day 4

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

  • 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

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

Hackfests/GtkBrno2012/Notes (last edited 2012-02-21 13:42:46 by MatthiasClasen)