On Mon, 2008-07-14 at 11:47 +0200, Bernd Jendrissek wrote: > > The grip: > > - knows how to draw itself > *** > > - calculates its own location from the object's geometry data > *** > > - updates its location when object geometry changes. > > - updates object geometry when manipulated by view/controller > > The section marked '***' is where the Peters and I seem to disagree - > I've put that knowledge in libgeda, but I gather they want it to be in > gschem. Obviously I think my way is better. :) Of course the grip's > graphical representation and mouseability live in gschem. Have a look > at my branch (opaque-objects-20080712) and look for grip_foreach_func > - easier than my trying to explain it here in prose.
I guess I'm being pedantic with this example, but there could be different ways to have grips manipulate an arc or circle. (Bounding box / centre + radius are two which spring to mind for circles). 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 ;). > I believe that "geometry" should include knowledge of which points are > "special": the endpoints of a line, vertexes in a polyline (imagine), > corners of a box. Even if MVC purists might pull their nose up at > this, I find it useful. To me, usefulness > purity. > Ok, so you're proposing putting part of the controller code in libgeda.. (teaching which points are special, and presumably providing code to manipulate an object by dragging those points). No harm there, I'm just not sure where it should live. I'm all in favour of adding notifications to OBJECTs (perhaps "proxied" / "multiplexed?" to callbacks registered to a whole PAGE of OBJECTs). I've flip-flopped between whether using GObject for this is a good idea or not. I think we should avoid it at the lowest level. -- Peter Clifton Electrical Engineering Division, Engineering Department, University of Cambridge, 9, JJ Thomson Avenue, Cambridge CB3 0FA Tel: +44 (0)7729 980173 - (No signal in the lab!) _______________________________________________ geda-dev mailing list [email protected] http://www.seul.org/cgi-bin/mailman/listinfo/geda-dev
