08-27-2015 02:00 PM
After a lot of back and forth, and many graphics, we are going to change the wire appearance. The almost-certainly-final-appearance is this:
The wires will only shift with data color, not data pattern.
Many users have given us a general requirement that channels look "totally distinct from other wires" and they did not like the one that 2015 shipped with (distinct but not enough, and hard to tell the core data type). This is where we have ended up. This is your last chance to provide feedback, but unless there is a counter proposal that is strongly accepted by the community, this is probably final.
08-27-2015 02:38 PM
Looks good! Does color also adapt to user-defined LVClass wire colors?
08-27-2015 03:06 PM
I would have to see that on a diagram with a bunch of normal wires and classes, but I am not sure it is visually distinct enough. I think the curved wires you proposed were the distinct change that reallly pushed ones perception of them to be outside of the data flow. These just say to me different data but same flow. Also not all coders have good color perception where the distinction is even less that is why shape is more imporatant. But then I started on B/W version of LV.
Didn't get the support on this before so I doubt it will have much impact, but it is my $0.02 worth.
08-27-2015 03:43 PM
JackDunaway wrote:
Looks good! Does color also adapt to user-defined LVClass wire colors?
You have to ask? I'm hurt! 🙂
08-27-2015 03:46 PM
The curve wires introduce too many problems with the editor environment itself -- figuring out how to manipulate them with all the various scripting functions, the editor gestures for making space, etc., was more than we could afford to bite off. If we ever get a new graphical environment, we might consider something like that.
And, no, not all the data colors are visually distinct. Some, like integer and picture string, are identical. But we aren't able to encode the pattern at all without looking pretty much identical to the various refnum wires running around.
08-27-2015 04:37 PM
AristosQueue wrote:
JackDunaway wrote:
Looks good! Does color also adapt to user-defined LVClass wire colors?
You have to ask? I'm hurt! 🙂
Maybe this was actually more of a subversive technical question.
I've had fun times with cross-context LVClass loading in codegen contexts, so I'll be interested to see how this is implemented (that is, if you are gleaning this color information in password-less G in a codegen context ).
08-27-2015 04:44 PM
OK, so I tried to replicate the existing and proposed channel wires using existing datatypes (including custom class appearances) to try to get an idea of just how 'unique and distinct' the two candidates are. I could get a lot closer to the proposed channel wire type than the existing, but that was by creating a custom class and intentionally looking to replicate the look. I'm not sure which I prefer, so I'm gonna sit on the fence.
08-27-2015 05:10 PM
Jack: I have no idea what you mean, but we'll "glean it" the same way we glean it for drawing a class FP terminal.
08-29-2015 11:34 PM
Like Scott, I would need to see this in an actual diagram. I don't have 2015, so I can't say I really grokked these wires yet. In an attempt to assimilate the concept, I made this modification to the producer consumer sample project that ships with LV about a week ago, but I still can't say I'm on board:
In this example, there are two events which both write to the same channel.
Anyway, in one of the other threads I made a post with some rough mockup wires, but that didn't seem to make it past the moderation, so here it is again:
08-31-2015 10:02 AM
tst wrote:
Anyway, in one of the other threads I made a post with some rough mockup wires, but that didn't seem to make it past the moderation, so here it is again:
It did make it. We saw it and took it into account.
tst wrote:
but I still can't say I'm on board:
Your specific objections include...? 🙂 Is it just that you wouldn't use it yourself or you feel that it is a problem for LV to include this notation?