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.

[AristosQueue (NI)]

I object to the use of the term "spider web" in this context. It is excessively hyperbolistic. You have one broken wire that happens to have two or more branches. It is hardly a spider web. That overstates the nature of the problem in the extreme in my opinion. Overall, while I agree the feedback may be improveable, I think you're blowing the threat posed by the current feedback far out of proportion.

In other words, "You just added a wire branch that broke the one wire you are currently working on. Either undo (ctrl+z) that branch OR replace the sink node with something that accepts the source type OR go find the source of the wire and change its type to something compatible with all of the highlighted endpoints."

That, by the way, calls attention to one of the reasons I like breaking the whole wire -- breaking the source of the wire helps me see where upstream I need to go to make my next edit when refactoring. Breaking all the branches helps me see all the types that have to be made compatible.

It may be that going to the black broken wire is what is inappropriate. Perhaps we could somehow highlight the entire broken wire but still draw it as a good wire except for the broken segment? That might be the compromise point I'm looking for.

[AristosQueue (NI)]

Something like:

[altenbach]

>Something like:

Yes, that's pretty much a digest of my idea picture.

(and yes, I sometimes do get "spiderwebs", e.g. if I have two heavily branched good wires and accidentally connect them somewhere by a slip of the mouse. It's not just a theoretical possibility. :D)

[AristosQueue (NI)]

> Yes, that's pretty much a digest of my idea picture.

Yes, but the big shift from your idea picture is that the whole wire is still marked as "having a problem", even if it doesn't draw as broken. That's still key, IMO.

[altenbach]

Ah, now I see. From a quick glance I thought it was some fancy object wire. 😄

I assume that the marked wire would stay when ctrl+b is pressed. Right?

[AristosQueue (NI)]

> I assume that the marked wire would stay when ctrl+b is pressed. Right?

That's a separate discussion.

My inclination is, "Ctrl+b would still wipe out the entire wire." My reason is that the whole wire is, to me, broken. The problem could be the source, could be the sink.

I really don't see the branch as necessarily the thing that is at fault. To me, it is just dumb luck that one of the sink terminals happens to match the source terminal. You've got a wire that is clearly flawed somehow. I don't think you can derive user intent from it in any way, shape, or form. If LV is going to retain part of the wire, it's because LV must be able to believe that part of that wire is intended. That's not an assumption I'm prepared to make.

[AristosQueue (NI)]

Your predicate is that the user created the problem by drawing the wire branch.

But the issue could as easily be created by doing a Replace on the source node. During a Replace, the fact that some things downstream happen to match doesn't necessarily imply that the Replace was a good thing to have done if not everything lined up after the replace. I'd be conservative in what I considered to be "good wires" in this case.

I think that the decision of which wires are broken, and thus which wires will be removed by ctrl+b, needs to be made without regard to the edit history of the VI, so I am reluctant to accept your argument that it is necessarily the branch that is the problem.

Make sense? (Not "do you agree?" but "do you see where I'm coming from?")

[altenbach]

> Yes, but the big shift from your idea picture is that the whole wire is still marked as "having a problem", even if it doesn't draw as broken. That's still key, IMO.

OK, I definitely don't want to have the wires even fatter. I see no problem with the good wire left unmarked. in the worst case maybe it could be bleached.

Yes there are many possible problems why a wire could be broken, for example:

• no source: OK break the entire wire!
• more than one source: I was trying to address that with the edit history suggestion, else just break the entire wire.
• One valid source: All wire branches going to a compatible sink should not be broken (even if there is a coercion).
• No sink: Wire should be bleached, but not broken.
• No valid sinks: wire should be bleached up to the first braching point, broken afterwards.

> My inclination is, "Ctrl+b would still wipe out the entire wire." My reason is that the whole wire is, to me, broken. The problem could be the source, could be the sink.

I think if the above five rules are applied first, it is sufficient to only remove the "really" broken wire segments.  I run into many cases where this would help me a lot.

> I think that the decision of which wires are broken, and thus which wires will be removed by ctrl+b, needs to be made without regard to the edit history of the VI, so I am reluctant to accept your argument that it is necessarily the branch that is the problem.

I agree that this is probably better and more consistent. We always have ctrl+z if things turn black after a mistaken connection.

I sitll do believe that the brokenness needs to be more precise as outlined with my points above. Salvage any good parts!

(Of course we also have these dreaded dynamic data wires that can be connected to almost anything. 😞 Boo!)

[AristosQueue (NI)]

> I see no problem with the good wire left unmarked.

Therein lies our difference of opinion. You see them as good wires with bad branches. I see them as bad wires with some branches that are marginally less bad than others, potentially salvageable.

Bleaching? No. It needs to look broken and stand out MORE on a diagram than the good wires. I don't suggest a particular UI for doing this -- the existing change to black works fine, in my opinion, but I see sense in your suggestion for it to render more like a good wire... just so long as it retains its "hey, look at me, I'm part of the problem not the solution!" status.

> it is sufficient to only remove the "really" broken wire segments

I disagree. If I'm hitting the ctrl+b key its because something is totally messed up and I want to wipe the diagram and start over. I only hit that when I'm so far gone I've lost track of my diagram. I don't want it holding onto anything that is likely a mistake, and that includes these so-called "good branches".

[Manzolli]

I think that altenbach and AristosQueue have both good points.

Showing with a broken wire what LabVIEW understand is good can be really helpful. Then a new shortcut can be created to remove only the bad branches. I suggest [Ctrl]+[Alt]+[B]. The shortcut [Ctrl]+[B] remain unchanged, removing the whole wire, "good" and "bad".

In a case mentioned with two different sources and two different sinks, LabVIEW can also have more than one option to solve the consistency. Then another shortcut can rotate among the possible solutions, showing good and bad wires, in other words, what will stay and what will go with [Ctrl]+[Alt]+[B]. Once the user find one option that fits his needs, he uses [Ctrl]+[Alt]+[B] to remove only the bad branches. If no good option is presented, the user can remove the whole thing with [Ctrl]+[B], undo last operation that broken the wire, or manually fix it.

I have no suggestion for the shortcut to rotate among the solutions.