Ben Jackson wrote: >On Sat, Oct 20, 2007 at 10:32:57AM -0700, joe tarantino wrote: > > >>On 10/20/07, Ben Jackson <[EMAIL PROTECTED]> 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@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user