Harmonize cross-view interaction

[GoogleCodeExporter]

This is a collector entry for all issues relating to the
harmonization/synchronization/unification problem.

Original issue reported on code.google.com by andre.knoerig@gmail.com on 29 Jan 2010 at 4:56

[GoogleCodeExporter]

Jumper items, ground plane and maybe other single-view-parts currently generate
visible abstract wires in the other views.

Original comment by andre.knoerig@gmail.com on 29 Jan 2010 at 4:57

[GoogleCodeExporter]

Issue 799 has been merged into this issue.

Original comment by irasc...@gmail.com on 30 Jan 2010 at 12:31

[GoogleCodeExporter]

Issue 755 has been merged into this issue.

Original comment by irasc...@gmail.com on 30 Jan 2010 at 12:32

[GoogleCodeExporter]

Issue 497 has been merged into this issue.

Original comment by irasc...@gmail.com on 26 Apr 2010 at 7:48

[GoogleCodeExporter]

Issue 890 has been merged into this issue.

Original comment by irasc...@gmail.com on 6 May 2010 at 8:47

[GoogleCodeExporter]

This morning's idea: rather than going in the direction of making the views 
less similar, in terms of which wires and parts are represented in each view, 
go the other direction: all wires, traces, parts, ratsnests, and so on, exist 
equally in all three views, the per-view difference being visibility.  This 
might end up making synchronization much easier.  

The first rule, which would already apply to comment 1, is that if a part isn't 
visible in a view, any wire drawn to it also shouldn't be visible.

Original comment by irasc...@gmail.com on 15 Jun 2010 at 7:48

[GoogleCodeExporter]

r4259 makes some progress on the issue in comment 1

Original comment by irasc...@gmail.com on 15 Jun 2010 at 10:05

[GoogleCodeExporter]

Here's an sync problem to consider.  In pcb view drop two parts, say two LEDs, 
and a via.  Connect one leg of one LED to the via, and connect one leg of the 
other LED to the same via.  

What should schematic view show?  Currently you would see the two LEDs with a 
ratsnest between. I think this is ok.

What should breadboard view show? Currently you would see the two LEDs, with 
two legs showing green, but no wire between. I think a "real" wire should be 
generated between the two LEDs.  Sticking with comment 7, this means that the 
same wire should then be added back into pcb and schematic views (but "real" 
wires are invisible in that view).

Something similar occurs with copper fill parts, or the ground and power 
symbols in schematic view. The equivalent part in breadboard view is the 
breadboard.  But there the method is to generate ratsnests in the other views.  

Original comment by irasc...@gmail.com on 15 Jun 2010 at 6:40

[GoogleCodeExporter]

Issue 966 has been merged into this issue.

Original comment by irasc...@gmail.com on 15 Jun 2010 at 6:56

[GoogleCodeExporter]

Issue 989 has been merged into this issue.

Original comment by irasc...@gmail.com on 15 Jun 2010 at 8:32

[GoogleCodeExporter]

Issue 838 has been merged into this issue.

Original comment by irasc...@gmail.com on 15 Jun 2010 at 8:41

[GoogleCodeExporter]

A follow-on to comment 6.  

Each view has its own special wire, that doesn't appear in the other views: in 
schematic and pcb view, this is called a trace, but in breadboard view this is 
called a wire.  Nevertheless, it might be possible to unify all of these by 
making them all instances of a Trace class.    

A trace drawn in any view may generate new connections which would generate 
ratsnests, and depending on the rules of the other view, may also generate 
traces.  For example, drawing a trace linking two connectors that were previous 
electrically isolated, would create ratsnests in all three views, and which 
would also generate a trace (i.e. a wire) in breadboard view.

The idea is that all three views have the same ratsnests. At the moment I'm not 
sure whether every view has the same traces (the traces native to the other two 
views wouldn't be visible).  

Original comment by irasc...@gmail.com on 19 Jun 2010 at 7:41

[GoogleCodeExporter]

Issue 911 has been merged into this issue.

Original comment by irasc...@gmail.com on 5 Jul 2010 at 5:15

[GoogleCodeExporter]

add the idea of making ratsnests optional to this discussion

Original comment by irasc...@gmail.com on 6 Jul 2010 at 11:03

[GoogleCodeExporter]

While the core idea from comment 6--all parts and wires exist in all views but 
may not be visible (i.e. the user is not aware of invisible parts)--still feels 
like the right implementation path, the approach to ratsnests has changed, and 
it's not clear whether a given ratsnest exists in all views.  

However, with the  new minimum-path approach to ratsnests, it might be a good 
time to think about the relations between views in terms of behavior that is 
not now "in harmony". For example, if you connect two connectors in breadboard 
view, this will generate a ratsnest line somewhere in schematic and pcb views.  
However, if you draw a trace between two hitherto unconnected parts in pcb 
view, this generates a "real" wire (and maybe even a breadboard) in breadboard 
view.  I would argue that we should take the same approach: generate a ratsnest 
in breadboard view.  That a ratsnest line in a given view says "you've made a 
connection in some other view, it's up to you to resolve this connection in 
this view".  This approach would prevent the really ugly messes that users have 
been complaining about, but as long as you're working in breadboard view, no 
breadboard ratsnests appear, so novice users wouldn't have to understand 
ratsnests until they went to the other views.

It's harder to make the case for "disconnection harmony".  At present, if you 
disconnect a connection in breadboard view, this may remove traces in PCB and 
schematic view.  However, if you disconnect a trace in pcb view, this doesn't 
affect connections in breadboard view. We currently resolve this in PCB view by 
using ratsnest deletion.  I wonder whether there should be a setting available 
so that users could turn disconnection harmony on or off.  Off mode is the 
default, and disconnection is anharmonic.  But if you turn on the mode, then 
disconnecting a trace would disconnect connections in breadboard view.  If 
we're using ratsnests in breadboard view, then a disconnection in pcb view may 
only mean eliminating a ratsnest in breadboard view. 

Original comment by irasc...@gmail.com on 24 Sep 2010 at 6:27

[GoogleCodeExporter]

+ 1000 :)

The disconnection is indeed weird, but can probably be looked at later.

Original comment by andre.knoerig@gmail.com on 1 Oct 2010 at 10:59

[GoogleCodeExporter]

Issue 1111 has been merged into this issue.

Original comment by irasc...@gmail.com on 3 Oct 2010 at 6:59

[GoogleCodeExporter]

Back to comment 15.  The disconnection issue seems obvious (this morning).  If 
you create a wire (or trace) between two hitherto unconnected connectors in a 
given view, then it will (possibly) generate a ratsnest line in the other views 
representing that new connection.  (We're all agreed on this.)  

If you then delete that original wire, it's unambiguous: the ratsnest line (if 
any) in the other views is removed because the connection has been broken.  
However, if you create a wire in breadboard view, and then in some other view 
draw a trace along that same connection, then if you delete the wire in 
breadboard view, you get a ratsnest because the connection is not broken.  To 
break the connection you'd delete the ratsnest in breadboard view or delete the 
trace in the other view.

Original comment by irasc...@gmail.com on 15 Oct 2010 at 7:59

[GoogleCodeExporter]

Issue 1110 has been merged into this issue.

Original comment by irasc...@gmail.com on 7 Feb 2011 at 7:26

[GoogleCodeExporter]

Issue 914 has been merged into this issue.

Original comment by irasc...@gmail.com on 8 Feb 2011 at 9:05

[GoogleCodeExporter]

Unfortunately, there's a difficulty.  Imagine you are in PCB view, and you draw 
a trace between two connectors that were previously unconnected.  In the 
current version of Fritzing, a new wire, connecting those two connectors will 
be created in breadboard view. We've all agreed this is ugly.  But is it useful 
in the following way--it keeps those two parts connected, even if the user 
decides to make that trace autoroutable, and during the next run of the 
autorouter, that trace is removed.  

In other words, when you connect a pair of connectors, in any view, what you 
are really doing is joining those connectors into a net.  And a net is 
represented by a constellation of ratsnests and wires (traces) in such a way 
that not every possible connection within a net is visually represented. 

So I am leaning toward the idea of keeping a view-independent net model data 
structure, and giving it the following asymmetric behavior: drawing a wire 
between two connectors would still join them into a net, but deleting a wire 
does not affect the net (except maybe deleting the wire you just drew).  
Instead, there's another operation that allows you to remove a connector from a 
net (which may delete wires or ratsnests as a consequence).

Original comment by irasc...@gmail.com on 12 Mar 2011 at 11:45

[GoogleCodeExporter]

Issue 1253 has been merged into this issue.

Original comment by irasc...@gmail.com on 21 Jun 2011 at 8:07

[GoogleCodeExporter]

Issue 1303 has been merged into this issue.

Original comment by irasc...@gmail.com on 2 Jul 2011 at 8:45

[GoogleCodeExporter]

This IS the next release.  With one current exception, no more distractions 
will be accepted.

Original comment by irasc...@gmail.com on 14 Jul 2011 at 12:17

• Added labels: Priority-Critical
• Removed labels: Priority-High

[GoogleCodeExporter]

Original comment by irasc...@gmail.com on 9 Oct 2011 at 8:25

• Added labels: Milestone-1.0

[GoogleCodeExporter]

Re comment 21.  While it may be useful to have a manipulable view of the actual 
underlying net, I no longer think it necessary. The majority of cases will 
follow one of these two paradigms:

-- creating a wire in some view and deleting it in that same view
-- drawing wires in breadboard or schematic view and using the autorouter in 
pcb view

In these paradigms, the underlying net is preserved (in the autorouter case, 
deleting the traces doesn't change the net because the net is still represented 
by the wires drawn in the breadboard or schematic view).  Even if the user 
draws wires in PCB view and autoroutes, the net is preserved because the user's 
drawn wires are marked "do not autoroute".  

The only behavior that breaks the underlying net is drawing traces, marking 
them autoroutable, and running the autorouter, because the original net can now 
be deleted.  So the trick is that when autorouting, a representation of the 
underlying net has to be preserved before deleting any traces.

Original comment by irasc...@gmail.com on 28 Dec 2011 at 12:01

[GoogleCodeExporter]

at last. closing the omnibus issue.  report current problems as individual bugs.

Original comment by irasc...@gmail.com on 3 Jan 2012 at 7:16

• Changed state: Fixed