On Mon, Jul 14, 2008 at 12:30 PM, Peter Clifton <[EMAIL PROTECTED]> wrote: > 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).
I see grips as libgeda-owned equations that libgeda must at all times and knows how to satisfy. gschem would only be responsible for telling libgeda "Here, you gave me a special point at X, and your name for it was GRIP_ARC_CENTER, and i just moved it to Y; solve your equations please!" gschem shouldn't know how to do the math to find the circle intersecting three given points, for example. > 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. The way I think about it is that both gschem and libgeda know some aspect of the geometry. libgeda would work with world-coord-centric concepts (solve this linear equation to find that intersection), and gschem would work with screen-coord-centric concepts (draw an arc from pixel X to pixel Y with sweep angle T). > 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. I think libgeda thinks in world coordinates (that what's stored in the object anyway) so the "pixel" shouldn't even exist as far as it (libgeda) is concerned. > 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 think it might be inevitable... sounds like the Bridge pattern (apologies for all the GoF names). In fact http://en.wikipedia.org/wiki/Bridge_pattern shows an example that reflects how gschem / libgeda want to be split. >> 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. Note that libgeda would be free to expose far more "special" points than gschem really cared about. One example is an arc's center - currently dragging the grip there changes the radius a bit abruptly, but it could equally well *move* the center. libgeda could expose both GRIP_ARC_CENTER and GRIP_ARC_RADIUS, both at the same point, and leave it up to gschem to remember only one of them. > I'm all in favour of adding notifications to OBJECTs (perhaps > "proxied" / "multiplexed?" to callbacks registered to a whole PAGE of > OBJECTs). If these notifications passed from OBJECT up to PAGE then we could get rid of the ubiquitous "toplevel->page_current->CHANGED = 1;" > 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. I think the gschem "ConcreteImplementor" classes should be GtkWidget's, and the drawing area a GtkContainer that remembers (in world coords) where the "ConcreteImplementor" instances are. I'm fairly convinced though that OBJECT should be a GObject, even if it's only so we don't have to rewrite g_signal_connect and friends. _______________________________________________ geda-dev mailing list [email protected] http://www.seul.org/cgi-bin/mailman/listinfo/geda-dev
