Re: GtkCanvas requirements?

[Carlos Garnacho <carlos imendio com>]

Hi!,

On Mon, 2007-04-23 at 14:03 -0400, Havoc Pennington wrote: 
> I certainly have not sat down and exhaustively tried to figure this out.

Oh, nice list below, I was somehow thinking a shorter in scope, less
tangential, set of changes.

> 
> There is a fair bit of cruft in the core; if you were starting over, I'm 
> sure you'd want to just kill GdkWindow for example, and many other "Xlib 
> leakages" such as how some of the events work.  You'd want to be 
> Cairo-only, use interfaces instead of objects for the core APIs (widget, 
> container), rethink GtkContainer and its common subclasses (as 
> HippoCanvas does), fix the theme system, blah blah. The list could get 
> pretty long.
> 
> The question is which of these are cosmetic cleanups that aren't really 
> worth it and which add new capabilities, and how long is the new 
> capabilities list. Probably not nearly as long as the cosmetic list.
> 
> Replacing the core with a more canvas-ish solution would not have to be 
> done all in one shot, though; the WidgetCanvasItem and CanvasWidget 
> provide a lot of interoperability. You could also have some of the 
> existing widgets implement the CanvasItem interface directly, for 
> example GtkEntry could be both a GtkWidget and a CanvasItem.
> 
> There's no real disruption to the current core while building a new 
> canvas-style core either, in fact I'd suggest evolving the canvas stuff 
> outside of GTK+ for at least a couple of years. It is probably also true 
> that certain "heavy" widgets such as TextView and TreeView never benefit 
> from conversion to a canvas-like model.

I agree this is a great idea for a testbed independent to GTK+, but even
in this case you could only test a subset of the things mentioned here,
other ones could prove to be hardly interoperable with the current
GtkWidget/GdkEvent functional details (Events handling, GdkWindow
revamp, ...).

IMVHO, such testbed should become directly a gdk/gtkwidget proof of
concept experiment, with two or three widget implementations to play
with, and such codebase could be reused later when it proves to be a
substantial improvement.

But, even being the canvas a great excuse to begin this effort, I don't
think it's going to offer enough improvements to the canvas itself to
deserve such a long wait, I think leaving potential API users with the
current canvas buffet for (say) these two years would harm us in the
medium/long term.

Regards,
   Carlos