On Thu, 2006-08-31 at 13:03 +0200, Marco Pesenti Gritti wrote: > Goocanvas has a view/model split at item level too. There is an > ItemModel and and ItemView, and the Item interface has a create_view > method. IHMO this introduce needless complexity, especially in the > event handling. > > Mouse events are signals on the ItemView, so you have two options to > listen for item events: > > 1 Subclass Item and ItemView and handle signals in ItemView > 2 Handle events from the CanvasView (which therefore needs to know > about his Model internals) > > None of these is really acceptable.
I don't see the problem with (1) for large applications. That is standard model/view stuff. For simple apps you can connect signal handlers to the item views. This isn't that hard (it is easier in the latest release). > I can see the usefullness of model/view split at item level in a > widget system (Swing for example) where logic and presentation are > clearly separated. But in goocanvas Model is totally about > presentation (stroke-color, fill-color, line-width to cite some of the > SimpleItem properties). > The simple items are all basic shapes, but for real-world use applications would use their document objects as the model. I agree that the model/view split does complicate it a bit. But it can also help a lot for larger apps. Damon _______________________________________________ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list