Re: GTK+ canvas?
- From: Damon Chaplin <damon karuna uklinux net>
- To: Marco Pesenti Gritti <mpgritti gmail com>
- Cc: gtk-devel-list gnome org, Havoc Pennington <hp redhat com>, "Gustavo J. A. M. Carneiro" <gjc inescporto pt>
- Subject: Re: GTK+ canvas?
- Date: Thu, 31 Aug 2006 14:16:58 +0100
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
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]