On Mon, 2009-03-09 at 15:09 -0400, Behdad Esfahbod wrote: > Alberto Ruiz wrote: > > 2009/3/2 Behdad Esfahbod <beh...@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 _______________________________________________ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
