Re: New 'GObject' as base for GtkObject?

[Tim Janik <timj gtk org>]

On Tue, 7 Dec 1999, Federico Mena Quintero wrote:

> >  - gtk arguments are a pretty poor abstraction of per-object properties, they
> >    just provide very primitive type information like int, pointer, float and
> >    it is impossible to monitor object state changes because an object
> >    property changes are not routed through the argument system exclusively.
> >    (one of the GnomeCanvas' biggest problems is the lack of notification
> >    upon argument changes, so it's for instance hard to keep track of the
> >    movement of a GnomeCanvasItem, eventhough it does route all item changes
> >    throguh the argument system).
> 
> I have one comment about this.
> 
> The canvas is a display engine.  It is not designed to be your main
> data structure.  You should know where your canvas items are; after
> all you put them there in the first place.
> 
> For applications where you want to use the canvas correctly as a
> display engine, you should use a model/view architecture, and
> implement the view(s) in terms of canvas items.

federico, i use a *true* model/view abstraction in beast, and
you can easily tell from the sources.
but since that thing you call "view" is actually an interactive
display that can react to user events, you need notification
for certain events such as pointer clicks movements or keypresses.
but you don't want to always handle everything in your event handler,
to ease implementation and abstraction, it is often *far* more
convenient to only monitor certain properties, e.g. the x,y coordinates
of an item, instead of catching all possible sources that can cause x,y
alterations.
so for instance the link items that connect multple item groups
together:


   +---------+                         +---------+
   | group 1 |---------link----------->| group 2 |
   +---------+                         +---------+

it is far more convenient to have the link's starting and ending
coordinates update themselves automatically from group 1 and group 2
x,y coordinate change notification callbacks, than to always update
the link's coordinates from all event handlers of group 1 and group 2
(they shouldn't even need to know about the link) and alternative
code portions that may set a group's x,y coordinates from e.g.
parasites in your data model abstraction.

note, that this doesn't interfere with the model/view abstraction,
rather it aids you in abstracting a specific item's purpose, and
allowes the application to keep track of GUI related data which is
important if your data abstraction/view model is actually a
data abstraction/edit model.

just because you need a basic major abstraction of the data you
want to represent on the one side, and the GUI on the other side,
doesn't mean no further abstraction is required _inside_ both parts
anymore. and to get further abstractions working in either part,
you still need notification between different entities (even if
limited to one part) that correlate in some way.


> 
>   Federico
> 

---
ciaoTJ