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
- 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
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
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.
- 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