Change the color of different classes in the project explorer

[Jeff-P]

Currently all classes in the project explorer are the same blue color:

But it is possible to change classes color on the block diagram, both wires and objects in the following window:

It would be nice if you could change the color of the classes in the Project Explorer to easily differentiate between different classes, for example

The second class from the top has been changed to differentiate it. This would be nice when I have a lot of classes in my projects.

[AristosQueue (NI)]

It's not a bad suggestion, but there are some difficulties to be addressed.

First and foremost: the glyph in the project tree is used to indicate the file type. Different glyphs mean different *types* of files. I think there would be many UI experts who would object to us mixing metaphors there. You can make the argument that classes are special because they *define* a type, and thus coloring an entire inheritance tree makes some sense. I'd need to hear more people react to this -- it isn't a slam dunk good idea.

What would you suggest we do we do with the default icon? Today, cubes are blue today and the wires are red. We try very hard to avoid using red in icons because we use that to call attention to things that are broken. If we changed the default of all the cubes to red (even the darker red that we use for the wire), that would violate that constraint.

[tst]

One problem here is that this also has the potential to create a lot of noise in the project window, which would make it completely unusable, if people customize a lot of the wires.

If people don't customize most of the wires (and most probably don't), then if your project organization is good, you would probably get streaks of the same color and this would mainly be good to find a class which was misplaced.

How about letting the user change the color of a virtual folder? That would give you some level of change.

AQ, all you need to do is change the default wire. Think of the marketing possibilites - "LV 2014, now with BLUE class wires...". 🙂

[smithd]

Thats definitely a very good point about the noise situation...once the project gets complex it could easily become confusing.

I really like the idea of changing the color of virtual folders or entire inheritence trees, though--I think its less coherent than matching icon to wire, but it would allow for clearer organization in the project without getting messy. Even just switching the glyphs around some would be nice. It could be overused, but this:

makes way less sense than this:

[Jeff-P]

What if there was a limited set of colors you could change your class icon to? Red could be excluded from this color set to avoid conflicts and it would still give the ability to differentiate classes. The default would still be the blue box.

I also quite like the idea of being able to modify the color of the virtual folders.

[dthor]

I think being able to modiy the virtual folder colors is a good alternative to the original Idea. Modiying class icons... that I'm not so sure about, for the same reasons Aristos Queue mentioned.

[JackDunaway]

+1 to the original idea. Symbio GDS already implements this exact feature, and it's quite useful to visually identify classes without necessarily reading the names of the classes in the project tree. (The same principle applies when scanning the color icons on smartphones - you can remember and visually sift through apps more quickly when they're different colors)

---

AQ wrote:

the glyph in the project tree is used to indicate the file type

---

I think Jeff-P is just asking to change the color of the cube, not the cube itself. It would default as blue, but the developer could opt to change the color.

---

tst wrote:

How about letting the user change the color of a virtual folder?

---

+1 to another good idea. 

[Jeff-P]

Yes, I am just talking about changing the color of the cube, not actually being able to change the icon to something different.

[Intaris]

For me, the colour change should be implemented.  The Glyph (geometrically) stays the same, it's only the colour changing so I although NI likes to treat us LV programmers as stupid sometimes I think we'll manage.  People programming LVOOP are not likely to be a part of the "no programming required" herd.

[AristosQueue (NI)]

You can't ask for the glyph to stay the same and change color... that is a change to the glyph. In the current project context, that color change would/should indicate a new file type. We could retrain user expectations -- and, again, I'm not opposed to the idea -- but it would be a retraining of meaning.

Let me be more direct: I hope someday to add interfaces, traits and generic/template classes to LabVIEW. Won't happen any time soon, but each of these would likely be some sort of colored cube. Particularly the generic/template class -- since it is a class -- would be most likely to be a different colored cube. Allowing non-file types to use colored cubes limits the glyph space available for the future. You can say that each of these could be the cube plus decorations. True, but the decorative space is limited by access scope and source code control. It gets tricky.

I definitely oppose changing the default wire color. We went to a lot of work to find a color that didn't match any of the existing color themes so that if you had a class that fit into one of the existing categories, you could customize the wire accordingly while retaining the object wire pattern. I think if we did do this, we would need to change the existing cubes to match the current wire color.

[Intaris]

AQ Wrote:

I hope someday to add interfaces, traits and generic/template classes to LabVIEW

You sir are my new hero.

That's the best possible reason to make me agree with NOT changing the colour of the classes in the project viewer.....