Hi, I have found a bug in the logic of previously attached patch. New patch will follow soon but first I want to clean up it a bit more and test.
On Jan 12, 2008 8:32 PM, Peter Clifton <[EMAIL PROTECTED]> wrote: > > On Sat, 2008-01-12 at 02:37 +0000, a r wrote: > > I tried to improve the way nets are being routed. See the attached > > patch (against v.1.3.0). It only deals with new nets (moving and > > copying works as before) and currently does not take into account > > device pins. > _ > I like it, although the switching between |_ and | did confuse me a > little at first. > > Can you describe in words what the changes are doing? I have tried the > code, but couldn't immediately quantify what the new logic was. There are several ideas behind the logic: 1. start drawing a new net with a segment perpendicular to the segment from which the net was started. 2. (t.b.d) if the net starts from the end of an existing net or a pin, start with a segment extending that existing net/pin. 3. (buggy) If there is no preferable direction start with a longer segment and continue with shorter. 4. Invert the logic if Shift key is pressed (existing feature) Overall, the idea is to make the logic behind drawing nets more intelligent and "intuitive". Currently all nets always start with a horizontal segment (or vertical if Shift is pressed) which does not help much when drawing a schematic. > It probably wants to be run under valgrind or gdb too.. I made gschem > crash whilst playing drawing nets with it: > > It complains muchly when libgeda happens to "consolidate" two lines > []----[]------[] into one []---------------[]. This is done in libgeda, > and is a great cause of headache, since it happens at an unexpected time > (during the undo code of all things IIRC). You have to be careful what > pointers you have about, or what linked list you're looping over if > there is any chance of those still being used when an object is delete. Hmm.. I'll try to nail it down. I guess, it happens in the object iteration loop but I couldn't recreate the problem. If you could please help me with this crash that would be great. > Another possible logic to consider (which I've seen in some pacakge, but > can't remember which..) is to have a net drawing like this: > > 2. X-Axis becomes fixed when you: > | > \|/ > -------- <--- 1. (Y-Axis already fixed from previous segment start) > | > | /|\ > |/--- 3. Click here, but | > ------------------------------ 4. this last horiz. segment > | can still move up and down. > \|/ > > Ending on a pin or double clicking (perhaps) would end drawing. This is mostly equivalent to the logic I want to implement (point 2). > Each click constrains one axis of the previous line segment joint, and > one of the place where you clicked. IIRC, It also adds a single segment > at a time, making the: > > -------- | > | or | > | -------- jump a little more intuitive. > > > Just food for thought.. I'm not suggesting you change your > implementation. (Having had the Debian guys just try to land me into > making a generic "extra menu" package by blocking my "Electronics" menu > package, insisting something more "generic" is needed, I know that isn't > a fun situation to be in). > > There is also a "magnetic nets" patch on the s.f. tracker (although it > probably needs a bit of cleanup and bringing up to date). Something > we'll look at again after 1.4.0 is out. I can imagine more elaborate scheme involving a full-blown routing algorithm. But unless it is done perfectly it is going to cause more problems than a simpler but more predictable solution. Cheers, -r. _______________________________________________ geda-dev mailing list [email protected] http://www.seul.org/cgi-bin/mailman/listinfo/geda-dev
