[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: gEDA-dev: Hiding location of grips from gschem
On Mon, Jul 14, 2008 at 12:30 PM, Peter Clifton <pcjc2@cam.ac.uk> 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
geda-dev@moria.seul.org
http://www.seul.org/cgi-bin/mailman/listinfo/geda-dev