[geda-user] How smart is gschems 1.9.1 rubberbanding?

[Stefan Salewski]

While doing some more cleanup, I noticed that I have missed rubberband
support in my peted tool. I have not really missed it, I think when I
used gschem some years ago for the last time I always deactivated it.

But I understand that people may want it, and it may be useful indeed.

I just started thinking about how rubberbands may work -- my first idea
was that connectivity should be always preserved, and that we should
avoid diagonal nets. Just launched gschem 1.9.1 -- seems that
connectivity can break, and that we may get diagonal nets when moving
objects around. Is this intended, is this what we want? I have no idea.
I just do not want to spent some hours of work for my own rubberbanding
and then discover that that gschems way is better.

I think there was one suggestion for improving gschem rubberbanding
postet to this list, maybe one or two years ago. Has someone still a
reference?

[Stefan Salewski]

Post by Stefan Salewski
and that we may get diagonal nets when moving
objects around.

For example, what surprises me:
When we move in gschem the horizontal net to the right,

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

we get this:

\
\
\
----------

My initial idea was to let the vertical net unchanged, but maybe gschems
behaviour is indeed better for this case? At least it is more rubberband
like.

[Kai-Martin Knaak]

Post by Stefan Salewski
When we move in gschem the horizontal net to the right,
|
|
|
----------
\
\
\
----------
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.

Post by Stefan Salewski
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(>---

[John Griessen]

Post by Kai-Martin Knaak
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.

+1 for practical utility. Could be a time saver over no rubberband mode, or leaving gaps.

[Kai-Martin Knaak]

Post by Stefan Salewski
But I understand that people may want it, and it may be useful indeed.

Count me as one of the users who want it.

Post by Stefan Salewski
I just started thinking about how rubberbands may work -- my first idea
was that connectivity should be always preserved, and that we should
avoid diagonal nets.

+1
This is how network lines should behave by default.
In addition, it should be possible to suppress rubberbanding on the fly.
E.g. if [shift] is pressed while initiating a move event.

Post by Stefan Salewski
Just launched gschem 1.9.1 -- seems that
connectivity can break, and that we may get diagonal nets when moving
objects around. Is this intended, is this what we want?

It is on my list of warts ;-)
Rubber banding should never result in non perpendicular nets. IMHO, it
would be better to disconnect than to make orthogonal lines slanted. The
disconnect would not go unnoticed, since the disconnected ends get one of
those large, red markers.

Good rubberbanding would involve a bunch of heuristics. There are some
non trivial constraints. E.g. new segments should never result in
shortened connections. Sometimes it is better to introduce an additional
segment in the middle. Sometimes, the segment should be at the end of
the stretched line.

Just my two cents.

---<)kaimartin(>---

[Stefan Salewski]

Post by Kai-Martin Knaak
It is on my list of warts ;-)
Rubber banding should never result in non perpendicular nets. IMHO, it
would be better to disconnect than to make orthogonal lines slanted. The
disconnect would not go unnoticed, since the disconnected ends get one of
those large, red markers.

Yes, but if we manually reconnect the open end we may do it wrong.

Post by Kai-Martin Knaak
Good rubberbanding would involve a bunch of heuristics. There are some
non trivial constraints. E.g. new segments should never result in
shortened connections. Sometimes it is better to introduce an
additional
segment in the middle. Sometimes, the segment should be at the end of

That is an interesting point.

Generally on-the-fly netlist generation would be good, to detect
whenever netlist has changed unintentionally by moving objects around.
For gschem that may be no problem -- for me it is currently, I have no
netlist generating code, and it was never my goal to write it, because
PCB can import schematics directly, and for people needing a netlist
export gnetlist is available. At least I will do it not now, maybe
later, after the first working release of.

[Stefan Salewski]

Post by Stefan Salewski
Generally on-the-fly netlist generation would be good, to detect
whenever netlist has changed unintentionally by moving objects around.

Well, should be not that difficult, I do not need a real netlist which
takes into account netnames and generates a special output format, but
only to find connected net segments. If I put the endpoint in a Hash,
that should be simple and fast, and finding the few T-shaped connections
should be not hard also, I am doing something similar already for
drawing the connection markers. Should take only a few ms for Ruby's
byte code interpreter, still fast enough for online check.

So maybe something like a Button "Reset Netlist" which stores current
state and turns red when netlist changed...

[John Griessen]

Post by Stefan Salewski
a Button "Reset Netlist" which stores current
state and turns red when netlist changed...

That would do it, yes.

If you want to add parts or wires, just push the button, then
rubber-banding will be ready again for doing a select area and move...

[John Griessen]

Post by Stefan Salewski
Is this intended, is this what we want?

No, preserving connections and avoiding shorts is what is wanted.
The value is in being a conceptual short cut compared to redrawing all moved connections.
Instead of diagonal, lines could be in steps as needed to avoid shorting out.
Avoiding shorting out may be more AI logic than you want to try programming!

A simple kind of rubber-band mode that is valuable is select instances and net segments,
then when a move starts, the selected set does not change shape, the unselected set
does not change position, and nets to preserve connectivity
fill in with two-right-angle-segments-with-one-common-point, or diagonals if that would cause shorts.

Often, two-right-angle-segments-with-one-common-point do not work well, as in connections between two
parallel rows of pins when one row is moved away and to the side. Then one would need
three-right-angle-segments-with-two-common-points to fill in between moved and stationary sets of instances and nets.

Sometimes rubber-band moving is only a conceptual short cut and takes a lot of time to do.

A good way to get quick results would be to just do the diagonals, then use a tool on selected set
to convert them to rectilinear nets that do not change the netlist. Then scoot those around to suit
your aesthetics. A one net at a time tool could be just a mode with mouse actions: click-drag
to convert a diagonal to rectilinear and influence where right angle points are. Keep them from
changing the netlist, and when the mouse moves in a direction, move the nearest bend point with it
while keeping netlist same, and only affecting the adjacent two points that are bend points or
connected to a pin.

Too many words, needs a drawing...gotta go though...

[Kai-Martin Knaak]

click-drag to convert a diagonal to rectilinear and influence where
right angle points are.

I wouldn't mind a special mode for a single net. The big advantage of
rubberband comes with moves that involve many nets.

---<)kaimartin(>---

[Vaclav Peroutka]

Post by Kai-Martin Knaak
I wouldn't mind a special mode for a single net. The big advantage of
rubberband comes with moves that involve many nets.

In work, I started to draw schematics in Zuken and it is more intuitive for
me. Look at this video:

I would love to see such behaviour in gschem, too.

Vaclav