Re: gEDA-dev: Hiding location of grips from gschem

[ehennes-at-NOSPAMsbcglobal_dot_net]

On Jul 14, 2008, at 3:30 AM, Peter Clifton wrote:
> Since gschem already needs to know how to draw each primitive libgeda
> object, implementing knowledge of grip locations in gschem isn't the
> only reason gschem has to special case handling of the different
> objects, so I'm inclined to leave the "controller" part in gschem.
>
> For the cairo branch, libgeda's ideas of object bounds are also a
> problem.. the rendered object on screen may bloat by a pixel or so due
> to anti-aliasing, and it isn't particularly nice to have to add extra
> margin to the libgeda returned bounds to account for this.
>
> Unfortunately, fixing the latter problem appears to lead to a
> sub-"model" in gschem (per "view" if you will). This is a place which
> could store / use inked screen coordinate bounds - if we wanted to.
> Hopefully we don't need to do this though ;).

Hmmm.  If OBJECT became the "per view" data, then another object could  
be created to store just the pure model data.  In this case, OBJECT  
could store grips (or be a grip factory), know about and cache screen  
coordinates, and know how to draw itself into the view.  It would not  
need event notification.  This new object would store data and provide  
event notification.  When data changed in the model, the view would  
get the change notification, find the corresponding OBJECT, and have  
the OBJECT update itself.  For an update, OBJECT would have a  
reference to the pure model data, extract the relevant properties, and  
recalculate it's members.

Does this solve the MVC partitioning debate?  I like the property  
change notification.  Implementing this potential solution would seem  
to require quite a bit of work, however.

Ed


_______________________________________________
geda-dev mailing list
geda-dev@moria.seul.org
http://www.seul.org/cgi-bin/mailman/listinfo/geda-dev