No subject

Tue Sep 4 21:45:45 EDT 2007

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
> <ben at ben.com>
> http://www.ben.com/
>
>
> _______________________________________________
> geda-user mailing list
> geda-user at moria.seul.org
> http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
>

------=_Part_13192_15196534.1192901577239
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

<div>On 10/20/07, Ben Jackson &lt;<a href="mailto:ben at ben.com">ben at ben.com</a>&gt; wrote:<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
On Fri, Oct 19, 2007 at 02:26:49PM +0000, Kai-Martin Knaak wrote: &gt; On Wed, 17 Oct 2007 16:16:23 -0700, Ben Jackson wrote: &gt; &gt; &gt; File a SF bug and point me at it and I&#39;ll see about fixing it. &gt;
 &gt; done. (ID 1816572) &gt; &gt; Looking forward to fix for this crippling non-feature, There are a few things going on here: 1)&nbsp;&nbsp;If you move a line or its endpoint:&nbsp;&nbsp;For purposes of rubberbanding,
 it is considered connected to all of the line segments whose ends overlap the moving line&#39;s end(s).&nbsp;&nbsp;The specific issue you report is due to the short diagonal segment being so short that the end lines overlap each
 other.&nbsp;&nbsp;In fact, a line where both endpoints overlap the moving point (the joining line in your case) won&#39;t even necessarily pick the right end of the line.&nbsp;&nbsp;That&#39;s easy to fix, but doesn&#39;t address the real problem.
</blockquote><div> 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.&nbsp; In the case that Kai-Martin showed earlier in this thread, there are three segments and 4 endpoints in the &quot;pick region&quot; that must be sorted through.&nbsp; It seems as if one of the endpoints gets dropped.
 I think you&#39;ve found the issue with the lines overlapping (i.e. adjacent vertices being closer together than the line width).&nbsp; 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?
 </div> <blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">2)&nbsp;&nbsp;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&#39;t
 control where it jumps back onto the grid), only one end of the line will move. Now both of these things would be &quot;solved&quot; if touching both ends of a line just moved the whole segment.&nbsp;&nbsp;Your tiny segment would not stretch,
 but instead it would remain in the same shape and the other long segment would stretch.&nbsp;&nbsp;Not terrible, not fabulous.&nbsp;&nbsp;For the pad case (or polygon case), this is probably the right thing.</blockquote><div> Actually, there are many cases (most?) where I think this solution would work quite well.&nbsp; 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: &nbsp; If the endpoints are farther apart than one line width, then pick the nearest one (easy case) &nbsp; 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.
 &nbsp; 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.&nbsp; (This is the case that fails most often now when it picks up the endpoint on the wrong line or doesn&#39;t move all the endpoints).
 </div> <div>You might have to differentiate&nbsp; between a &quot;tiny&quot; segment that is shorter than one grid spacing vs. one that is longer than one grid spacing.&nbsp; Quite often I generate these short lines by routing with &quot;snap to pins/pads&quot; turned on.&nbsp; Then you are almost always guaranteed to cause a tiny segment to occur right at the end (often &quot;inside&quot; the pad).&nbsp; 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.&nbsp; (Yes, I realize that this may be difficult to do given the way the data is stored.)
 </div> <blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">For the line case, another alternative would be to restrict the rubberbanding to exactly-connected lines.&nbsp;&nbsp;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.</blockquote><div> Does the data structure end up with an entry for the &quot;segment&quot; that covers the short distance between the on-grid and off-grid point?&nbsp; 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.&nbsp; This would allow you to &quot;stretch&quot; the short segment into one that you could later modify.&nbsp; If both endpoints move, you can&#39;t modify this intersection without deleting and re-adding things.&nbsp; (This is really a lot like the case I outlined above.)
 </div> <blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">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.&nbsp;&nbsp;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.&nbsp;&nbsp;This is also tricky because we don&#39;t know what order we&#39;ll see the lines (and the data structures are again not helpful).</blockquote><div> The 3+ line intersection case would be farther down my list.&nbsp; I don&#39;t encounter that too often unless I&#39;m building up a&nbsp; &quot;geometry&quot; like a transmission line or taper.
 From the very little I&#39;ve looked at this code, I can tell that it is something that is beyond my ability to dig very far into.&nbsp; I really appreciate that someone is taking a look at this. Thanks, 
Joe T </div> <blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">I&#39;m open to suggestions. -- Ben Jackson AD7GD &lt;<a href="mailto:ben at ben.com">
ben at ben.com</a>&gt; <a href="http://www.ben.com/">http://www.ben.com/</a> _______________________________________________ geda-user mailing list <a href="mailto:geda-user at moria.seul.org">geda-user at moria.seul.org
</a> <a href="http://www.seul.org/cgi-bin/mailman/listinfo/geda-user">http://www.seul.org/cgi-bin/mailman/listinfo/geda-user</a> </blockquote></div>

------=_Part_13192_15196534.1192901577239--