Break bad wire branches, not the entire wire!

[altenbach]

Currently, having one misconnected wire breaks the entire wire tree and pressing ctrl+b wipes out everything. Poof!

In the vast majority of (my) scenarios, a broken wire is due to a small problem isolated to one branch so it does not make sense to drag the entire wire from the source to all valid destinations down with it and break everything in the process.

Here is a simplified example to illustrate the problem (see picture).

In (A) we have mostly good code. If we add a wire as shown, that wire (and VI!) must break of course because such a wire would not make any sense.

However, it does not make sense to also break the good, existing branches of the wire (the cluster in this case), but that is exactly what we get today as shown in (B). If we press ctrl+b at this point, all broken wires will disappear and we would have to start wiring from scratch (or undo, of course :)). Even the context help and tip strip is misleading, because it claims that the "source is a cluster ... the sink is long ...", while that is only true for 25% of the sinks in this case!

What we should get instead is shown in part (C). Only the tiny bad wire branch should break, leaving all the good connection untouched. Pressing ctrl+b at this point should only remove the short bad wire.

The entire wire should only be broken in cases where nothing is OK along its entire length, e.g. if there is no source or if it connects to two different data sources, for example.

Summary: Good parts of a wire should remain intact if only some of the branches are bad. Wires that go to a destination compatible with the wire source should not break.

(Similarly, for dangling wires, the red X should be on the broken branch, not on the good source wire as it is today)

Implementation of this idea would significantly help in isolating the location of the problem. Currently, one small mistake will potentially cover the entire diagram with broken wires going in all directions and finding the actual problem is much more difficult than it should be.

[X.]

It seems that the following approach would potentially statisfy both Altenbach and AQ:

All wires that are currently broken would still be broken BUT they would have a color providing information about the best-guessed type for each segment of the wire.

Wherever a type transition would be needed, a "conversion" bullet (or something with a different shape to avoid confusion with the numeric type conversion bullet) would be introduced.

Currently, my main qualm with the current behavior is not so much that it breaks wires, but that the information on the type conflict is usually put at an arbitrary location:

[altenbach]

Yes, it a matter of philosopy.

Is the entire wire a single entity or can each wire segment be inspected and judged independently?

• Does one bad apple really spoil the whole bunch?
• Mitgegangen, mitgehangen?
• Cling together, swing together?
• Fly with the crows, get shot (ctrl+b) with the crows?

My argument is still that a branched wire could be inspected with more granularity. I still believe that a wire segment going from a defined source to a compatible sink is perfectly fine and shold not show any brokeness. Yes, I think I understand all the arguments given in the above discussions, but I still believe in my original opinion. 

It is not useful to the beginner if LabVIEW just says: "something is broken here, could be anywhere marked in black (and yes, as in the picture right above, the x is actually in the wrong place!). Alternatively, it could say "I have a problem creating just this wire branch because the sink is not compatible". It seems much more targeted and helpful.

Of course there are scenarios where everything should break, and LabVIEW is still allowed to do that. 😄

[AristosQueue (NI)]

The red X and direction/type arrows are in the same location on every wire except for loose ends in order to make it easy to glance at and see the nature of the problem. If it drifted around on the wire, I don't see how it would be nearly so useful, but I could be talked into it.

X's proposal is an intriguing approach.

[JÞB]

OK, I'll chime in.  Wire labels can attach to wire segments.  Those red "X's" on broken wires (I dislike those and thanks for giving me an ini option to remove them) should be specific to the broken wire branch.

Broken wire branches should be treated differently than broken wires.  Wire branches are already treated as unique entities with labels.  CA seams to be asking for that treatment to be up-developed (Is that a word?)  My vote: Break the branch not the wire!

[JackDunaway]

> Maybe enough has moved around in LV that I'd be ok with this these days. Or maybe I'll remember exactly what made me shy away from it

in marketing and economics, this is called a leading indicator. *edit: rather, perhaps, trailing indicator.

[altenbach]

As another example of the confusion caused by the current behavor, let's have a look at the code I made for this idea.

With the idea implemented, it would have been sufficient to have a single timestamp array and a single timestamp as inputs, branching the wire to the three code segments. If I would currently do that, ALL input wires would be broken, even going to the primitives that would accept them verbatim. With the idea implemented, only the wire branches going to the middle primitive would be broken, better illustrating the issue.

[RnDMonkey]

So far I like the gist of X's suggestion the best. I feel that the entire wire could have the "under construction" stripes on it while retaining the underlying type information, with a few rules:

1. Insofar as a wire branch matches, or can be coerced from, a source, the data type of the source should be shown on this branch

2. Insofar as a wire branch does not match, and cannot be coerced from, the source type, the data type of the sink should be shown on this branch

3. If any branch of a wire is incompatible, the entire wire shall display the "construction stripes" to cue the user that the wire has issues

My suggestion/restatement of wire cleanup rules:

1. Ctrl+B either removes only the incompatible branches as indicated in #2 above (just as it removes dangling wire ends without removing good wires) OR:

2. Ctrl+B retains while-wire removal behavior and an additional Ctrl+Alt+B shortcut to only remove mismatched wire branches as opposed to the whole wire

I concede Stephen's point that you can easily run into situations (such as when replacing a control or auto-indexing an output tunnel) where no downstream sink is of a matching type, or some types just coincidentally match (or can be coerced from) the source wire, in which case I submit that the existing wire cleanup behavior is appropriate and is not incompatible with these suggestions, since all wire branches are on their own merits broken.

My preference is for wire cleanup to trim back incompatible wire branches but save any that can match, even if this may be entirely accidental. As it is now, 19 times out of 20 I only use Ctrl+B to remove dangling wire ends since full cleanup is so aggressive, and another 30 times I'm double-clicking on exactly the wire branches we are discussing so that I can remove only that branch. In short, wire cleanup is not very useful to me as it currently functions, but a little tweaking could make it very useful.

Notwithstanding any change to wire cleanup behavior, simply having the broken wire display modified to show source and sink types as described in #1-3 above would be a welcome boon. It conveys meaningful information where there is a noted lack of information, and that seems like a good thing to me.

[AristosQueue (NI)]

Further playing and the discussions in this thread have convinced me that there is merit to changing how we render and repair type conflicts on wires by keeping more of the wire unbroken. I don't know what the exact solution should look like, but I'll add my Kudos to the idea as something that should be investigated.

[tomsze]

Graphical programming should be more focused on user experience. This is only small part of LV I guess...