Monday

Engine API

  • Everyone agrees that there won't be GtkWidget* or GdkWindow* in the new engine API. It will be replaced by cairo_t*.

  • Carlos presents his work on GtkStyleContext, a way to push information to the engines' drawing functions.

  • It's pretty obvious that colors and fonts will be part of GtkStyleContext, but not whether it (i) should support arbitrary GObject properties, (ii) any information about the scene graph.

  • Discussion whether a single draw function prototype will suffice for the future engine API, or special casing e.g. for drawing box-gaps will be needed. It might suffice to draw the tab/text into the border area of the notebook/frame whatever, means the gap-filling primitive has to care about connecting correctly.
  • Open issue regarding engine API is how the drawing functions hook into the system. Does the engine have to register drawing functions, do we keep the vtable, or something else?

Animations

  • Handled by GtkStyleContext

  • Triggered explicitly by widgets
    • State changes on the whole widget would be done for the developer
  • Added a way to identify different widget regions so they could be animated independently
    • Themes get to know inside the paint functions whether its affected by some animation, the state it is for, and the progress
  • Got GtkButton partly working

    • And a test app in tests!

Tuesday

  • Agreed on GStyleSheet (CSS representation)

  • Try out a GStylable interface to query matched elements/pseudoelements (replaces current style properties)

  • Getting rid of the GDK dependency for engines in a 2.x compatible fashion
  • Agreed GtkStyleContext stores the GStyleSheet+GStylable queries results for a given match

  • Some work on shape support to handle events properly on shaped widgets.
  • Fixes in libcroco to support generic interfaces.

Wednesday

libcroco (Rob)

  • Finish turning the libxml selection engine into a generic selection engine.
  • Implement a libxml instance using the new, generic cascading interface.
  • Port the libcroco testsuite so it uses the slightly changed croco/libxml API.
  • Have stew and guiness for dinner.
  • Result: tests now using the libxml-support (which in turn uses the generic engine) work just as before.

Thursday

* Sell N810 so I can get more guiness and stew (Rob).

libcroco (Rob)

  • Fix memory leaks in the selection engine.
  • Contact inkscape developers about converging efforts upstream.
  • Submit libcroco patch for review.

Hit detection

  • Started a branch of carlos style context work to let engines return the basic shape.
  • Shape will be either a cairo_surface_t* or cairo_path_t* as they are client side.
  • Transformation matrix (cairo_matrix_t*) should be stored in case the shape is transformed to get hit detection into account.
  • Shape storage is a flag in GtkStyleContext.

Friday

Summary of the week

  • Get rid of style properties and replace with a single global padding option (GtkBin)

  • Get rid of GtkStyle and GtkRcStyle (Cody to work on a migration path)

  • API to draw onto a cairo context (hiding GdkWindow and GtkWidget)

  • Using CSS syntax for theme files
  • Using CSS rules to apple to the scenegraph
  • Use FreeDesktop icon name spec instead of a GTK stock icon name spec, and provide built-in icons

  • A GtkStyle replacement that is extensible (garnacho's GtkStyleContext)

  • Deprecate draw_polygon, _diamond and _tab (_shadow?)
  • New GtkStateType (bitfield)

  • List parts of complex widgets
  • draw_part() and small set of primitives (for text, arrow, line)
  • Animation support for both continuous animations and transitions
  • Hit detection for widgets with complex shapes, using either a cairo path or cairo surface returned from the engine
  • ARGB by default
  • Basic CSS support in default engine for 3.0 (the rest of the CSS support in another engine)

Projects/GTK+/NewThemeApi/Hackfest/Notes (last edited 2013-11-22 15:36:56 by WilliamJonMcCann)