Re: gtk_widget_draw()

[Benjamin Otte <otte gnome org>]

On Mon, Aug 9, 2010 at 10:17 PM, Havoc Pennington <hp pobox com> wrote:
> GtkSourceView would be one heavily-affected codebase if there are
> changes here.
>
I did not mention this explicitly anywhere yet, so I'll do it here:
My goal is to have all my changes minimize the effects on code that is
equivalent to GTK, i.e. the usual widgets people code, like graphs or
docks or even the simple ones like web browsers, canvasses or
textviews. For their use cases, a transition to new APIs should
ideally be possible using search/replace, but should not include huge
refactorings to new semantics.
To give an example: I think it's ok to make people change the name of
their paint function from foo_expose to foo_draw and remove the two
lines cr = gdk_cairo_create (event->window) and cairo_destroy(cr); in
that function. However, requiring widgets to rethink their whole
GdkWindow-using tricks is not a good idea.
That doesn't mean it won't be necessary - porting from gdk draw API to
Cairo is not always straightforward - but I'm trying very hard to
minimize that work.

> (One reason is, I'd love to see any downsides to just using GTK
> widgets inside Clutter removed; starting over on all the "hard"
> widgets, input methods, etc. on top of Clutter loses an awful lot of
> effort and functionality imo.)
>
I'm not sure if we can achieve that, or if we even should, but in my
dream world, someone is going to write a GDK backend using clutter.
And then a GdkWindow is just another ClutterActor. That would probably
give us the best of both worlds. How and when we get there and if GTK
will be called MX by then is left to the imagination of anyone
involved.

Benjamin