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 _______________________________________________ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list