Re: gEDA-user: sloppy rupper band mode

[Ben Jackson <ben@xxxxxxx>]

On Sat, Oct 20, 2007 at 10:32:57AM -0700, joe tarantino wrote:
> On 10/20/07, Ben Jackson <ben@xxxxxxx> wrote:
> > 1)  If you move a line or its endpoint:  For purposes of rubberbanding,
> > it is considered connected to all of the line segments whose ends overlap
> > the moving line's end(s).
> 
> That appears to be the problem: Either that it is picking the wrong segment
> or that it is leaving one of the endpoints behind (unpicked) that belongs to
> the short segment.  In the case that Kai-Martin showed earlier in this
> thread, there are three segments and 4 endpoints in the "pick region" that
> must be sorted through.  It seems as if one of the endpoints gets dropped.

New illustration  A---------BC-DE--------F, where B=C, D=E and B,C,D,E overlap

Well, that's what we've got to decide.  Either the bug is:  one gets
dropped, meaning the "right" behavior that dragging segment EF should
move points B, C, D along with E.  OR the bug is too many get included,
meaning the "right" behavior that dragging EF should only drag D.

I favor the latter, but I am not sure what the rule is by which I'd
exclude B.  Excluding C is easy, since we search by line I see C and D
at the same time.  In fact, I'm not sure the rest of the code would cope
if you added BOTH C and D.

> I think you've found the issue with the lines overlapping (i.e. adjacent
> vertices being closer together than the line width).  What about ignoring
> the line width while choosing the proper endpoint in the case when the
> endpoints are closer together than one or two line widths?

That makes it easier to pick D when considering segment CD, but you can
get the same result by simply picking the closer point.  I already made
that fix in my view when I noticed it was picking the "first" end every
time.  It's not much of an improvement, though.  You still get the weird
3-line-V structure.

[snip a discussion of how crosshair position could be used to select one
of the two solutions I described above]

> 
> Quite
> often I generate these short lines by routing with "snap to pins/pads"
> turned on.  Then you are almost always guaranteed to cause a tiny segment to
> occur right at the end (often "inside" the pad).  In this case, if there is
> a point that is exactly on the pin or pad and the pin or pad is moved, only
> the line endpoint exactly on the pin or pad should move.  (Yes, I realize
> that this may be difficult to do given the way the data is stored.)

Interesting preference.  I'm thinking of SMT pads that end up like this:

+---------------------+
|                  C--|---D
|   A             B   |
|                     |
+---------------------+

Where A and B are the points defining the pad and BC is the stubby segment
that steps onto the grid.  When you move that now, one endpoint of BC
stays behind.  The other endpoint along with the C-end of CD.  You end
up with one crazy diagonal connecting line CD and one line from B back
to approximately wherever the pad used to be.  That seems pretty useless
to me.  Actually, the initial creation of BC seems pretty useless, since
it adds nothing in the end.

> The 3+ line intersection case would be farther down my list.  I don't
> encounter that too often unless I'm building up a  "geometry" like a
> transmission line or taper.

I think the way I'm leaning now is to let the 3+ line case break or
behave oddly and fix the bug by simply taking the one closest endpoint
when doing line-to-line rubberbands.

-- 
Ben Jackson AD7GD
<ben@xxxxxxx>
http://www.ben.com/


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