Re: gEDA-user: 4-bit_12-LED.png (PNG Image, 1024x768 pixels)

[Peter Clifton <pcjc2@xxxxxxxxx>]

On Tue, 2007-04-10 at 13:10 -0400, DJ Delorie wrote:
> > *IF* this were done, we'd need probably need to track crossed
> > objects as well as connected objects, otherwise the drawing code
> > would have to check lots of lines for intersection at each redraw.
> 
> pcb does this rather efficiently using rtrees to keep track of what's
> where.  Since most net lines in schematics tend to be horizontal or
> vertical anyway, I think we can optimize this enough to be doable with
> minimal code changes.  Not that I know anything about gschem's
> internals, just guessing.

I just looked at rtrees - very interesting. I'm not aware of libgeda /
gschem using such a structure. It does keep a notion of "tiles" which
the drawing canvas is divided into, and for connectable objects, like
nets and buses, a record is made of which tiles they cross.

> > Perhaps another way to do it could be to allow arcs as net segments,
> > and introduce a tool to insert them. Auto-magically doing so is fine
> > too..  just like net segments are consolidated automatically at the
> > moment.
> 
> I really don't want to think of the problems involved with trying to
> move a net segment after doing that, though.

You have a point there, it would much complicate the necessary
rubber-banding, and many other operations.


An interesting separation would be to make a net defined by:

two end-points,

PLUS: a graphical representation, "prim_objects" which are lines, and
arcs - generated as necessary to display the net. This is similar to
"complex" objects.

We could allow picking up the line and moving it by its end-points, so
long as the prim-objects are regenerated as necessary. (Rubber-banding
would probably just draw an XOR line, and prim-objects would be
regenerated after). It is also a neat way to encapsulate the fact that a
net is a special type of line.

It does make me recognise a potential "glitch" with any implicit
jog-adding scheme though, because we don't know how the final line will
render, and where a side-net could be connected.

Currently, side-nets (T junctions) are only permitted (or identified)
for connections joints with at least one horizontal or vertical net. 

If we put jogs in the net, what if there is a real, desired connection
close to where the jog is formed:

WIREB (connected to WIREA)| |WIREC (not connected to WIREA)
                          | |
        WIREA            -+-+--
        ----------------/ o |  \--------
                            |
                            |

Should WIREB be contracted to the point where it meets the jog (probably
off grid), or should it miss-draw like I showed above?

What if a additional net-segment has a an end intersecting that point?

It would seem best to ensure lines _cannot_ "T" connect within the jog
section. (Unfortunately breaking the nice abstraction of the two
end-points, and the prim-objects which draw it).


Peter C




_______________________________________________
geda-user mailing list
geda-user@xxxxxxxxxxxxxx
http://www.seul.org/cgi-bin/mailman/listinfo/geda-user