Re: gtk_widget_draw()

[Havoc Pennington <hp pobox com>]

Hi,

On Wed, Aug 18, 2010 at 7:56 AM, Paul Davis <paul linuxaudiosystems com> wrote:
> On Tue, Aug 17, 2010 at 5:04 PM, Federico Mena Quintero
> <federico 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