On Mon, Aug 9, 2010 at 10:17 PM, Havoc Pennington <h...@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 _______________________________________________ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
