[prev in list] [next in list] [prev in thread] [next in thread] 

List:       gtk-devel
Subject:    Re: GTK+ canvas?
From:       "Marco Pesenti Gritti" <mpgritti () gmail ! com>
Date:       2006-08-31 11:03:41
Message-ID: c0ad901f0608310403o338ffdf2q115f584c4f6abc74 () mail ! gmail ! com
[Download RAW message or body]

[Attachment #2 (multipart/alternative)]


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

[Attachment #5 (text/html)]

<br>On 8/31/06, <b class="gmail_sendername">Havoc Pennington</b> &lt;<a \
href="mailto:hp@redhat.com">hp@redhat.com</a>&gt; wrote:<div><span \
class="gmail_quote"></span><blockquote class="gmail_quote" style="border-left: 1px \
solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"> Gustavo J. \
A. M. Carneiro wrote:<br>&gt;<br>&gt;&nbsp;&nbsp; It seems this HippoCanvas has no \
model-view split, yet I remember you<br>&gt; designed GtkTextBuffer/View with \
model/view.&nbsp;&nbsp;Do you consider model-view<br>&gt; unimportant, or simply just \
got &quot;prioritized away&quot;? <br>&gt;<br><br>I'm not sure, I'd have to look at \
GooCanvas or experiment myself. It's<br>certainly not required for Mugshot so I \
didn't think about it too much.<br>I can definitely imagine it complicates things. On \
the other hand, <br>conceptually for e.g. HippoCanvas it just means passing \
the<br>HippoCanvasContext to the size and paint methods, instead of \
having<br>set_context(), and probably moving the allocation to \
be<br>context_get_allocation() instead of storing it in the item. <br><br>For \
textview the reason we did it is to support e.g. split buffers in a<br>programming \
editor (like emacs C-x 2 or whatever)<br><br>A possible use-case for it with a canvas \
is something like a magnifier<br>item that is a view of another part of the canvas. \
But, how often do you <br>really need stuff like \
that.</blockquote><div><br><br>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. \
<br><br>Mouse events are signals on the ItemView, so you have two options to listen \
for item events:<br><br>1 Subclass Item and ItemView and handle signals in \
ItemView<br>2 Handle events from the CanvasView (which therefore needs to know about \
his Model internals) <br><br>None of these is really acceptable.<br><br>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). <br><br>Marco<br></div></div>



_______________________________________________
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list


[prev in list] [next in list] [prev in thread] [next in thread]