Where can we start?

Or, How can we actually move to a new theme API?

• Implement a new API using the existing API. This could even be implemented by a new gtk-engine.
• Implement the new API straight into GTK+, and then re-implement the old api using the new api, thus creating a compatibility layer for "legacy" gtk-engines.

New API straight into GTK+

This is an idea of a new layer of abstraction between the widgets and the drawing primitives. The idea is that an engine won't need to access the parent properties and struct memebers, instead, all the context needed should be provided through a context object. It will replace the string detail as it is used now.

• GtkStyleContext class: An object that contains an arbitrary number of style context properties. Plus parent window, widget style, etc. The idea is to avoid the need to crawl for widget properties, introspect parent objects by providing as much information as possible.

• Each context should be identified by an unique name. For example, the context for a Button in a ComboBox could have a "Button@ComboBox" string or something similar (ComboButton?). That would allow rc/css files to specify properties for that particular case of buttons. Consistence in choosing this context names should be encouraged.

• Backwards compatibility: A legacy engine fallback functionality would be needed for the migration path. The idea would be to call the primitives in this legacy engine and call the primitives and deduct the detail string from the context properties.

Behaviour

• GTK+ should ensure the background of the widget is initalised, and should assume the widget is transparent. This is currently not the case for progress bars where the background is not initalised, and not the case for entry widgets, where the background is assumed to be a certain colour.
• Composite widgets should be drawn in the context of the parent widget. E.g. treeview column buttons should be drawn with a "treeview" context, not just "button".
  • Just thought about this. In a treeview you could not only have the headers, but also a button cell renderer. So there should be a way to keep them apart.
• Basic render function

Widget drawing methods

These are methods that provide the basic functions you might need to draw a widget with. These are functions specific to drawing widgets, as opposed to any other type of drawing.

• trough
• slider
• check
• option
• button
• grip
• tab (position [top, left, right, buttom], state [active, inactive], row position [first, second, penultimate, last]
• data box (any widget you would normally expect to be black on white, e.g. treeview or text box)
• control box (similar to border, but with fill, used for toolbars)

Stylised drawing methods

These are more abstract drawing methods, but stylised to reflect the current theme.

• border (just draws a border with the specified style)
• line (draw a line with the specified style)
• arrow
• text (with state type)
• image (with state type)

Generic parameters for each function

draw_foo (caito_t *cr, char *context, int x, int y, int width, int height)

Context would be a string representing the exact name of the widget (or top level widget in the case of composite widgets) the function is being called for.