Style Context

• Containers would want to propagate something to their children (column-header, connects-{north,south,west,east}, ...)
• save/restore habilities
• could want to store several types
  • boolean/flags
  • doubles
  • ints
  • enums?
  • need examples about these!
• matching functions
• querying functions

Drawing API

• Pass a style context
• Pass a cairo context
• Pass transparency?
  • Possibly as part of the context
  • Transparency should be handled by engines
• Allow non-rectangular shapes
  • Composited
    • RGBA colormaps by default
    • Paint functions should consider the background "transparent"
    • Windows should actually be transparent by default
  • Non-composited: window shapes (would it happen that often nowadays?)
    • Fallback
    • Should be handled by widgets themselves

      • Maybe returning a GdkRegion?

        • gtk_paint_box needs it at least
• Merge functions together
  • vline/hline
  • extension/box with connect-foo
  • box/flat box?
• Deprecate functions
  • diamond
  • polygon
  • tab

Animations

• Problems
  • Paint functions are stateless
    • Seems a wise thing, else engines would have too much responsibility
    • Where/How do we begin the animations?
      • In the GTK side
        • either told by engine (progress bar animation)
        • or triggered by GTK itself (state changes)
      • needs cooperation from engines
  • Several items with different state on the same widget (tabs, expanders...)
    • Which one do we animate?
• What do we want to animate?
  • state changes
    • But these could just apply to parts of the widget
  • expander
  • progress bar (could be handled with GTK_STATE_ACTIVE?)
  • check button (idem) (inconsistent?)
  • option button (idem)

Context

• Roles: What the item being painted is going to represent
  • Default: used when widget has the default flag
  • Focus: usually a dotted rectangle
  • Background
  • Selection
  • Mouse selection: rubberbanding
  • combobutton
  • header
  • scrollbutton
• Elements
  • border
  • flat
  • shadow
  • checkbox
  • radio
  • handle
  • expander
• Placing Context (will widgets be able to handle RTL/LTR cases here?)
  • connects-top
  • connects-bottom
  • connects-left
  • connects-right
• state (Makes it sense to have them as flags)
  • prelight
  • active
  • selected
  • insensitive
  • default?
• colors
  • usual ones
  • symbolic names
• additional/custom flags?

Crack

• painting order ("z-layering") is handled by GTK+
  • This is a problem for i.e. focus and selection
    • Engines could want something more fashioned than a dotted rectangle (say, glow behind text)
    • Widgets however usually paint focus the last
  • Make paint functions pile up paint operations into a context
    • Push all operations at once

      • should we do anything wrt (possibly) painting to several GdkWindows?

    • Engines can specify the handling order based on the context, widget type, ...