Coersion Dots

[JÞB]

For the most part coersions can be broken down into two classes: lossy (e.g. 64L to I8) and safe (e.g. U8 to U16). Why is there only one color option for coersion dots?  Could the vi analizer have seperate settings for max allowable safe and unsafe  coersions?

[AristosQueue (NI)]

The ones you call "safe" are still potential performance pitfalls. There are two other classes of coercion dots that I can think of -- the upcast of refnums and the typedef-stripping/typedef-adding. We could differentiate lots of categories of coercion, but, honestly, there's not that much space on the terminals, and few colors that can be seen against the background of most nodes. They used to be grey, but lots of people complained they couldn't see them, so we changed them to red. That works better, but it does demonstrate we don't have a lot of options for differentiating kinds of coercion dots.

[JÞB]

I agree that several classes of coersion exist.  My dots are a vile green color (set with Tools>Options:Colors uncheck "use default")  Why not have more than one class of coersions?

[crelf]

The reason you can't see many colours is because of the contrast with the node behind them - so if the dot had a 1 pixel border then you could make it anything you wanted.  I know there's not much room, but I think 1 pixel border is acheivable.

[AristosQueue (NI)]

Jeff:

Having more than one class of coercion dot doesn't do us any good if no one can distinguish one type of dot from another. 

crelf notes that we could put a border around the dot to make it more distinctive. Our experience with wire drawing says that's not true. Although that might enable us to use any color for the coercion dot color, it wouldn't mean that people could actually distinguish what color that dot actually was. At that pixel size, even very different colors are hard to distinguish for lots of people, well beyond the usual color blindness concerns. It doesn't make sense for us to spend time trying to flag different coercion dots of different types if most people won't be able to readily distinguish them -- we'd be writing a feature that would be invisible to the majority of customers. We know its a problem because even things as big as a wire create color visualization problems when we do things like put the outer cyan border on a queue wire or the gray background on a LV class wire. Many people report that they cannot see the difference between a queue of integer and a queue of refnums because with the cyan border, the core color of cyan and the core color of blue look identical. These are folks who aren't normally color blind, but color proximity does funny things to human vision. With a coercion dot, you have a much smaller region than a wire, so the distinctiveness would be decreased further. 

[AristosQueue (NI)]

And, really, my central point is that it almost doesn't matter what kind of coercion dot you have. They are all places where you should investigate your diagram further and decide if that's really how you want it to look.

[JÞB]

Ok- so color based on coersions dependant on data loss is not the best feature.  I also suggested the VI analizer could have seperate settings for coersion class (or not).

[AristosQueue (NI)]

> I also suggested the VI analizer could have

> seperate settings for coersion class (or not).

Which is perhaps a good idea, but one I would hesitate to support.  If we start putting that logic into the VI Analyzer, we now have the logic of "why is this coercion dot here" encoded in the LV compiler and again in the VIs of the VI Analyzer. Keeping them in sync would be tricky, since those are completely different programming teams that maintain those pieces of code, and they're not even in the same language (C++ for one and G for the other). 

I don't like turning down ideas because they're inconvenient for LV R&D, but in this case, it just seems like something we would forever be messing up, to the detriment of users.

[Manzolli]

How about keeping one color (default red) and adding a tip strip with the coersion detail like [U16 -> I32] when the user hover over the coersion dot?

[AristosQueue (NI)]

Tip strip suggestion wins my support. I've added my kudos to this idea as long as the tip strip idea is what we go with.

[JackDunaway]

Tip strips? How about Context Help?