Color properties should default to colorbox data

[altenbach]

(As already hinted here, I think this deserves a seperate idea).

Property nodes have many items that accept color data (cursor color, plot color, bg color, etc). When right-clicking these and "create constant|control|indicator", we get a generic U32 type. Instead, we want a colorbox! Even more complex color structures, e.g. (colors[4] of a boolean) should have colorboxes as the innermost elements.

In all instances I have ever used these properties, I ended up replacing the U32 with colorboxes for code readability and simplicity.

Idea: when creating an input or output (constant, control, indicator) on any color property, we should get a colorbox (control, constant, indicator) instead of a plain U32 numeric. 

[smercurio_fc]

Interesting idea, though I wonder about its feasibility. How does one distinguish a "regular" U32 from a U32 that's a color value? Perhaps a new datatype is required, or would that be too radical? (Sort of like how in .NET you have a Color class.)

[altenbach]

Well, it could search the property name for the string "color", for example. 😄

I wonder how many exceptions this would need? How about a lookup list of all color properties?

[AristosQueue (NI)]

> How does one distinguish a "regular" U32 from a U32 that's a color value?

Alternatively, since R&D has to tag every property with things such as "Must post to root loop" or "Depricated" or "Not valid when VI is running", we could have one more flag that says "is a color"... That would save on having to change types all over.

[altenbach]

Just an additional note: A similar thing happens for clusters.

For example: I have a cluster (typedef), where one element is a colorbox. If I do a "bundle by name" and e.g. "create constant|control" on the color element input, I get a plain U32 numeric instead of a color box. This should also be handled the same way, if possible, so that we get a colorbox constant|control, etc.

[vt92]

I think it is a great suggestion. 

Message Edited by vt92 on 03-19-2010 02:31 PM

[JÞB]

Another great idea!  the dup reciently posted pointed me back here.  Ideally, these color constants shuld have tip-strips that display the RGB values on hover in edit mode

[altenbach]

(A duplicate of this idea has recently been posted. Here is a link for reference)

[Darren]

How about if, when you right click a terminal or a wire, if that terminal/wire is a U32, or is a data type that only contains clusters/arrays containing U32, then the right-click > Create pull-right would contain:

Constant

Control

Indicator

Color Box > Constant

                 > Control

                 > Indicator

In other words, a 'Color Box' pull-right allowing to you create color box elements where the U32 numerics would otherwise have been created. Would that feature sufficiently solve this use case?

[wiebe@CARYA]

@Darren,

How would that work for U32's in clusters (or arrays with clusters)?

I thing no alternative\workaround will be faster then QD, "box", CTRL+P.

[Darren]

The right-click menu would appear for a U32, or any nested type that only contains U32s (like clusters of U32s, or arrays of clusters of U32s). 

I agree that Quick Drop Replace will adequately solve this use case, but the right-click menu item is more discoverable for users who don't use Quick Drop or haven't incorporated Quick Drop Replace into their workflow.