On 10/20/07, Ben Jackson <[EMAIL PROTECTED]> wrote: > > On Fri, Oct 19, 2007 at 02:26:49PM +0000, Kai-Martin Knaak wrote: > > On Wed, 17 Oct 2007 16:16:23 -0700, Ben Jackson wrote: > > > > > File a SF bug and point me at it and I'll see about fixing it. > > > > done. (ID 1816572) > > > > Looking forward to fix for this crippling non-feature, > > There are a few things going on here: > > 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). The specific issue you report is due to the > short diagonal segment being so short that the end lines overlap each > other. In fact, a line where both endpoints overlap the moving point (the > joining line in your case) won't even necessarily pick the right end of > the line. That's easy to fix, but doesn't address the real problem.
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. 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? 2) If you move an element and one of the pads touches both ends of a > line (easy to do if your line is narrower than the pad and you don't > control where it jumps back onto the grid), only one end of the line > will move. > > Now both of these things would be "solved" if touching both ends of a > line just moved the whole segment. Your tiny segment would not stretch, > but instead it would remain in the same shape and the other long segment > would stretch. Not terrible, not fabulous. For the pad case (or polygon > case), this is probably the right thing. Actually, there are many cases (most?) where I think this solution would work quite well. Having an easier way in general to move a segment (or group of segments) while keeping the end points connected would be very handy. Maybe you pick the approach like this: If the endpoints are farther apart than one line width, then pick the nearest one (easy case) If the the pick point is closer to a grid point that lies on the line (or within one grid spacing to a point on the line) and more than one grid point away from both end points, pick up the whole segment. If the line segment is very short (less than one line width and less than 2 grid point spacings long and the pick point is closer to one endpoint than the other by at least one grid spacing then pick the nearest one. (This is the case that fails most often now when it picks up the endpoint on the wrong line or doesn't move all the endpoints). You might have to differentiate between a "tiny" segment that is shorter than one grid spacing vs. one that is longer than one grid spacing. 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.) For the line case, another alternative would be to restrict the > rubberbanding to exactly-connected lines. However, it currently works > in your favor if you make a hand-drawn line on-grid to an off-grid line > and only overlap without joining using an explicit segment. Does the data structure end up with an entry for the "segment" that covers the short distance between the on-grid and off-grid point? My preference in this case would be to move the segment (the segment endpoints really) and not any nearby points that are not on grid. This would allow you to "stretch" the short segment into one that you could later modify. If both endpoints move, you can't modify this intersection without deleting and re-adding things. (This is really a lot like the case I outlined above.) It could also pick one BEST endpoint to connect to (closest eg, although > the data structures are not really set up for this), but perhaps someone > really cares about a 3+ line intersection case. It could ignore points > that are (perhaps exactly) connected to segments that are already going > to rubberband, on the theory that one continuous line should only move > one point. This is also tricky because we don't know what order we'll > see the lines (and the data structures are again not helpful). 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. >From the very little I've looked at this code, I can tell that it is something that is beyond my ability to dig very far into. I really appreciate that someone is taking a look at this. Thanks, Joe T I'm open to suggestions. > > -- > Ben Jackson AD7GD > <[EMAIL PROTECTED]> > http://www.ben.com/ > > > _______________________________________________ > geda-user mailing list > [email protected] > http://www.seul.org/cgi-bin/mailman/listinfo/geda-user >
_______________________________________________ geda-user mailing list [email protected] http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
