This proposal is aimed to provide:

  • sane theming implementation, with all the features that could be expected in a modern toolkit
  • a coherent migration path for GTK+, not everything has to be ported at once, also providing a more feasible schedule wrt GTK+ 3.0



  • One per widget
  • Has API to add several style providers: each provider would have a priority
  • The style context merges the style from all providers, from lesser to more priority, provides API for widgets to query the resulting set.
  • Allows widgets to define named regions, such regions could have different style settings than the widget itself
    • notebook tabs
    • treeview rows
  • Enables the use of animations (only for state changes)
    • Provides API to notify on a state change
    • Handles animations
      • Bookkeeping of animation resources
      • Keeps track of which regions need invalidating
    • Theme engines get to know the progress [0..1] of the animation for a given state.
    • Enables widgets to add further context information
      • Specific API calls, widgets aren't supposed to change style information this way
      • Placing info: CONNECTS_[TOP|BOTTOM|LEFT|RIGHT] so the engine has a sense of interconnected elements
        • Spin buttons
        • Path bar / Breadcrumbs
      • Contextual information for named regions
        • First/last
        • Even/Odd
  • Allows widgets to query style settings
    • Initial set of properties, should mimic GtkStyle contents, plus a few more settings

    • widget style properties


  • Interface to be implemented by several objects
    • CSS or whatever is the replacement to GtkRC: Future plans
    • GtkStyle: Legacy settings until GtkRC is replaced

    • GtkSettings?: user font settings, custom colors

    • GtkStyleContext itself: Proper parent->child style inheritance

  • Their purpose is to feed GtkStyleContext with style info


  • Theme engine implementations
  • Methods to paint elements, pretty much like in GtkStyleClass

  • Cairo as first class citizen
  • Limited access to application/toolkit information
    • Its own set of getters so the GtkStyleContext is not exposed, no way to change anything in it.

    • Little to no knowledge about the actual widget, all necessary info should be already in the context

Miscellaneous objects/structs

  • GtkWidgetPath: Object to represent a full widget path with all its details: widget names, named regions, class name. Would be used by the style context in order to query information from providers.

  • GtkPadding: boxed struct to replace x/y thickness, could provide different padding for left/right or top/bottom

  • GdkColor should have alpha info

    • Need to check backwards compat, maybe could be done like GdkEvent private data.

Migration plan

  • We only need GtkStyleContext , GtkTheme and the GtkStyle implementation of GtkStyleProvider in place

  • Make gtk_paint_*() methods use new API underneath
    • Widgets would automatically start using the most basic set of features of the new API

At this point, we'd have a GTK+ using the new API, but taking style information from the old places.

Further changes, such as doing a CSS GtkStyleProvider implementation, or actually porting widgets to use the new API could be done on a one by one basis, and in the least disrupting way


CarlosGarnacho/ThemingProposal (last edited 2010-03-02 19:15:26 by CarlosGarnacho)