X-Authentication-Warning: delorie.com: mail set sender to geda-user-bounces using -f
X-Recipient: geda-user AT delorie DOT com
X-Injected-Via-Gmane: http://gmane.org/
To: geda-user AT delorie DOT com
From: Kai-Martin Knaak <kmk AT familieknaak DOT de>
Subject: Re: [geda-user] Re: How smart is gschems 1.9.1 rubberbanding?
Date: Sun, 10 Aug 2014 02:32:25 +0200
Lines: 72
Message-ID: <ls6eiq$30r$1@ger.gmane.org>
References: <1407607347 DOT 2887 DOT 13 DOT camel AT AMD64X2> <1407608776 DOT 2887 DOT 20 DOT camel AT AMD64X2>
Mime-Version: 1.0
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7Bit
X-Complaints-To: usenet AT ger DOT gmane DOT org
X-Gmane-NNTP-Posting-Host: a89-182-148-184.net-htp.de
User-Agent: KNode/4.12.4
Reply-To: geda-user AT delorie DOT com

Stefan Salewski wrote:

> When we move in gschem the horizontal net to the right,
> 
>      |
>      |
>      |
>  ----------
> 
> we get this:
> 
>     \
>      \
>       \
>  ----------
> 
> My initial idea was to let the vertical net unchanged,

I think so, too.

If the left node of the horizontal line is moved vertically, the node 
looses connection and we get two nets:

     |
     |
     |
 --
   --
     --
       --
         --

This leaves us with a broken net and a slanted line. Most probably not 
the desired outcome.


> but maybe
> gschems behaviour is indeed better for this case?

Well, I guess, it was easy to code.

IMHO, a good rubberband mode should mode should ensure at least one of 
these constraints by design:

1) preserve existing connections
   1a) never break a net
   1b) never add a connection in the process

2) keep all lines orthogonal. In schematics slanted lines are very 
unusual to say the least. So a slanted line will make the user redraw 
the net.

3) keep different nets a minimum distance apart. 
Imagine, two symbols A and B connected by three nets:

AAA---BBB
AAA---BBB
AAA---BBB

Now move symbol B vertically by a large amount. What should a 
rubberband mode do?

There will always be corner cases that a rubberband mode cannot handle 
without breaking one of the above rules. The current code does just 
lets it happen. But how about a slightly different approach:

First try to abide the rules. If this fails, turn the affected nets 
into rats similar to the way pcb handles not yet completed 
connections. Then it is up to the user to turn the rats into regular 
orthogonal nets. 
 
---<)kaimartin(>---