Renderer

This is an idea that is roughly based on a suggestion by Lieven van der Heide.

Instead of having a small and fixed set of drawing functions, we could have a string based system. This has the advantage that applications can register rendering functions (and default implementations) if they need them.

To be able to pass arbitrary data to the renderer, we would need a dynamic list of (string based) parameters. Each of these parameters would need to be wrapped into a GValue and passed with a list, array or hash table table to the function. The alternative is to have generic string based getter function for values like these.

Examples/Problems:

• - The ComboBoxEntry entry and button. As these are different widgets internally

  • one is only able to have comboboentry_entry and comboboxentry_button functions.
  - Scrollbar could be one generic renderer, that falls back to the box renderer.
  • Note that this approach could create a lot of inconsitencies. (Don't remember any reason why this would happen ...)
  - Applicationas and desktop enviroments can add new rendering functions
  • to the set provided by GTK+. eg. the nautilus pie chart.

It is possible to do this in an API/ABI compatible way. The general idea would be to at some point fall back to one of these renders old drawing functions (or something hardcoded).