Re: Gtk+ 3.0 Theming API Hackfest Minutes

[Owen Taylor <otaylor redhat com>]

On Mon, 2009-03-09 at 15:09 -0400, Behdad Esfahbod wrote:
> Alberto Ruiz wrote:
> > 2009/3/2 Behdad Esfahbod <behdad behdad org>:
> >> Alberto Ruiz wrote:
> >>> * All drawing funcitions to use a cario context and hide GtkWidget and
> >>> GdkWindow (Strong request from 3rd party toolkits)
> >> When we discussed this before, I among others suggested that this is wrong as
> >> it hardcodes cairo as the only supported drawing system in the API.  For
> >> example, one wouldn't be able to use OpenGL for drawing anymore.
> > 
> > Well, you can always get the native device of the surface. This works
> > for Windows and Mac native drawing APIs. You can then create an OpenGL
> > context out that (someone correct me if I'm wrong here).
> > 
> > A bit tricky, we might add facilities for that, but most engines are
> > going to use cairo anyway.
> 
> It's just about whether the API is extensible or hardcodes cairo.

Hardcode cairo!

I think it's more important to have a constrained well documented
drawing API between the the clients of the theme engine and the theme
engines than to worry about hypothetical "what ifs".

It's OK to have some sort of backdoor. But if you don't have:

 - Any client of the API passes in a cairo surface to the theme
   engine that is all the theme engine needs to know about.

 - Any theme engine can draw properly to an arbitrary cairo 
   surface that is passed in.

Then you've replicated the current broken ecosystem.

- Owen