On Mon, Jul 14, 2008 at 5:20 AM, <[EMAIL PROTECTED]> wrote: > The view/controller: > - contained a list of all the grips (view) > - could locate a grip given screen coordinates (view)
I've changed nothing in the above two. > - create a new list of grips when the selection changed (view) This would be cool; I think it'd be cleaner than the current out-of-band "rubber" geometries. > - respond to mouse events and manipulate the grip (ctrl) > > 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. > The object: > - stores geometry (coords, etc...) 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. > - sends events to listeners when geometry changes Definitely worthwhile, if my abstract symbols work is anything to go by. > No matter which way the grip implementation goes, I think it is an > important feature for the object to send some form of property change > notification. I agree; I added my poor-man's object notification on my "abstract-symbols" branch and it allowed me to delete whole pages of tightly coupled code that would recalculate and redraw text when the user changed an attribute. Instead, I had the attribute editor change the (libgeda) text object, and the object emitted a "changed" signal, which gschem could translate into the same recalculate / redraw events in a much simpler way. _______________________________________________ geda-dev mailing list [email protected] http://www.seul.org/cgi-bin/mailman/listinfo/geda-dev
