Carlos Garnacho wrote: > First of all we need to specify the feature requirements for the > canvas. The following is a list of features I think we should > consider, hope it's a good start, please add to it if there are others: > > - GTK+ suitable API. > - a11y support. > - Model/View split. > - Size negociation, height for width, width for height and natural size. > - object shapes, collision detection. > - animation framework (perhaps should be more tied to GTK+, GtkTimeLine > maybe?). > - get the offscreen rendering patch in. > - GtkPrint* integration. > - grouping/ungrouping. > - extensibility, being able to create new canvas elements with little > effort. > - DnD support. >
Sounds pretty good until this point. Benjamin just mentioned in IRC that *theming* is also pretty important. We want to be able to render the same canvas item in different ways for different themes. > - Integrate tightly GTK+ and the canvas, even making GtkWidgets > specialized canvas elements drawn with a certain layout in a canvas, see > Havoc's proposal [3] > I don't think the GtkWidget API and the GtkCanvas API shouldn't be tied together too much. I would like to see the canvas approch being "the new API" and the widget API to become some legacy API (to make app porting easier). As long as we can have these two things everything should be fine: 1. A CanvasWidget: a canvas item that can serve as a GtkContainer for GtkWidgets (so you can have widgets inside the canvas) 2. A WidgetCanvas: a GtkWidget that displays a GtkCanvas You can do everything you want with this structure, so I don't think there's a large need more (but maybe I'm alone with this opinion). Regards, Sven _______________________________________________ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list