Hi, On Wed, Aug 18, 2010 at 7:56 AM, Paul Davis <p...@linuxaudiosystems.com> wrote: > On Tue, Aug 17, 2010 at 5:04 PM, Federico Mena Quintero > <feder...@ximian.com> wrote: > > [ ... ] > > its quite amusing to me how what is being described is slowly > converging on something extremely close to a canvas model in many of > its most fundamental aspects. am i the only one seeing this? does it > matter?
See http://log.ometer.com/2008-03.html#7 perhaps. Another way to think of "canvas" (different than in the above slide deck), is what I call "just a canvas" vs. "toolkit stuff" - toolkit stuff is all the global singletons, the GApplication, the main loop, the window system abstraction layer. A really nice thing about HippoCanvas was that the canvas items didn't really see "above" themselves to parent items, or most of all they didn't poke at toplevel windows or a "stage" or a global backend thingy such as a display. Instead HippoCanvas is totally recursive - events get to leaf items by being sent to parent items that then forward to the leaf items, to draw the whole screen you just draw the root item, etc. This then makes it very easy to be in that gtk_widget_draw() type of world where you can draw items to other contexts such as to print them. I think both GTK 2.x and Clutter have fairly suboptimal code where there's a good bit of leakage of the global window system goo into the actors/widgets, and part of this thread is about mopping that up. A nice thing about having actors and widgets separate from all the "toolkit stuff" is that it makes it a good bit simpler to mix two different kits together. Anyway that's one aspect of this, and the other I think is more in the slides I linked to, which is that canvas items are generally more flexible than widgets (have transforms, don't have to be a rectangle, etc.) Havoc _______________________________________________ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list