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 [email protected] http://www.seul.org/cgi-bin/mailman/listinfo/geda-dev
