Re: gEDA-user: sloppy rupper band mode

[joeft <joeft@xxxxxxxxxxxxx>]

Ben Jackson wrote:

>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.
>  
>
The more explicit illustration helps...

I agree.  Either it should drag D with segment EF (my preference; it is 
simpler and more useful) or it should drag B,C,D along with segment EF( 
not preferred - it prevents stretching segment CD).  In the past I 
believe it was
dragging B & D along with segment EF, which was not useful.

>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.
>  
>
Creating the short segment (B-C) is a result of snapping to an off-grid 
pad.  Stretching this segment means moving point C, regardless of 
whether it was inside or outside the boundary of the pad to start with (?)

The situation I run into more often is that the pad points (A,B) are off 
grid, as is C, while D is on grid, but C is outside the pad (see 
below).  It may be simpler than the case you have drawn.  This is the 
picture that represents what I usually see.  Point C is off grid in 
either case.

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

Joe T

>>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.
>
>  
>



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