Re: GTK+ canvas?

["Marco Pesenti Gritti" <mpgritti gmail com>]

On 8/31/06, Havoc Pennington <hp redhat com> wrote:

Gustavo J. A. M. Carneiro wrote:
>
>   It seems this HippoCanvas has no model-view split, yet I remember you
> designed GtkTextBuffer/View with model/view.  Do you consider model-view
> unimportant, or simply just got "prioritized away"?
>

I'm not sure, I'd have to look at GooCanvas or experiment myself. It's
certainly not required for Mugshot so I didn't think about it too much.
I can definitely imagine it complicates things. On the other hand,
conceptually for e.g. HippoCanvas it just means passing the
HippoCanvasContext to the size and paint methods, instead of having
set_context(), and probably moving the allocation to be
context_get_allocation() instead of storing it in the item.

For textview the reason we did it is to support e.g. split buffers in a
programming editor (like emacs C-x 2 or whatever)

A possible use-case for it with a canvas is something like a magnifier
item that is a view of another part of the canvas. But, how often do you
really need stuff like that.

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 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).

Marco