Problems

GTK+ does sometimes assume nothing will be drawn, and then does not call into the engine.
Themes cannot take widget properties into account.
Most paddings are hardcoded inside applications.
Engines currently need to use the widget pointer to achieve some things.
When drawing the strings the color needs to depend on the color from the background. However, this color is often not known.
The widget_class, etc. lines are sorted in the order they appear in the gtkrc. Sorting them for relevance is better.
The margins in widgets have a fixed size and cannot change depending on the screens resolution.
Themes do not have a very fine control of the size and layout of GTK+ widgets.
There is a large amount of inconsistencies in how the different widgets are drawn.
Custom drawing for application specific widgets cannot be themed.
It is hard to fake widgets, both because engines sometimes rely on the passed in widgets, and because what GTK+ does is not documented/defined properly.
GTK+ engines draw directly on the X window. Passing in a cairo context could make scaling and other advanced features possible (eg. canvases).

Proposals

Context object
- Proposal: Use a context object to specify context information. A context object should be populated by widgets. API to push/pull context values to any widget. This API would be responsible for collecting the context information (eg. this is a button in a combobox/treeview header). The collected data needs to be exposed to the theme somehow.
/Styleable interface
- Proposal: A "Stylable" interface that any gobject could implement to provide styling functions and store theme data, including support for animations
/StackedDrawing
- Proposal: The drawing information is very much decoupled from the widget. Instead a context where all the information is kept is created. This context is modified to represent the widget that is being drawn. After a widget is drawn the information is poped again (ie. similar to cairo_save/cairo_restore). All widgets inside a container are affected by the containers style, as its information is still part of the context.
/CSS Style theme format
- Proposal: Create a new API to replace ?GtkStyle after the 3.x release cycle.
/NewAPI
- Proposal: Create a new API to replace GtkStyle after the 3.x release cycle.
/Classes
- Proposal: CSS style classes
/Renderer
- Proposal: Application extendable rendering architecture
/Animation
- Proposal: Animation framework for transitions and continuous animations

Task	Status	People
Create a page of GTK+ widgets (fix this tasks name)	(put link here)	Alberto Ruiz
Think about the artist's workflow when creating a theme. #workflow
Create a specification of how GTK+ widgets should be drawn #specification		Andreas, Alberto Ruiz, Benjamin Berg
Have the (above) specification for drawing reviewed by artists and other people #consistency		Andreas
Create mockups of a new theme syntax #syntax
Create a mockup engine #mockup	not yet started	Benjamin and ?
Deprecate GtkStyle when in some 3.x version

Here some improvements for GTK+ 2.x

Task	Status	People
Create an API for theme engines to dynamically create GtkRCStyles and set style properties on them	not yet started	Benjamin Berg