Add color to project explorer window to help break up content

[Daklu]

One problem I sometimes run into these days in large projects with lots of vis is that I lose track of where I am.  I'll know where in the project hierarchy I need to go to find what I'm looking for, but I have so many folders open it takes me a bit to figure out where to go to find that spot in the project.

What I usually do now is if I have a vi open I know is close to what I'm looking for in the project hierarchy I make that window active and hit ctl-shft-e to navigate to that location in the project.  I'll even open a sub-vi just so I can use ctl-shft-e to avoid having to navigate the project window.

I don't really know what the best solution to this is, but I think adding customizable color would help the situation a lot.  Some possiblities for additional color are background shading for rows of items, the virtual folders, or the lines that extend betweeen tree nodes when an item is expanded.

[tst]

I'm not sure that adding color would help, as it would probably create too much visual noise. How about adding a text box to the project window which will filter what appears in the tree? So, for example, you type "lvcl" into it and only items with that in their names are now displayed in the tree. I think I do like this, but I'm not sure. If you think it's good it would need to be posted as a new idea.

[Daklu]

The search box is a worthy idea, though personally I wouldn't use it much. I code with my left hand on the keyboard and right hand on the mouse. Typing is too disruptive. I either have to take my right hand off the mouse to type two-handed or take my eyes off the screen to type with my left hand. It breaks my flow.

oo much color could be a problem.  Giving every line a different color certainly wouldn't help.  I'm thinking of blocks of color, such as a single color for a class (or any parent project node that can be expanded) and all its contents.  What colors to apply and where to apply them would be user-selectable, so for example, in the project below I could color the RefFrameConv.testPublicAccessors class and it would apply the color to the class and all the items in the class.  However, if the private or protected folders already had colors applied to them, the new class color wouldn't override those.

Having thought about it a bit more, there are really two separate issues I'm having with the current project window.

1. The first is it isn't easy enough to pick out the important parts of a long list of project items.  When I'm scrolling through the project and stop, it takes a second or so to find the class or library names.  It's harder when there are several relatively small classes, like in this image, and if there is a lot of horizontal variation due to uneven nesting its even worse.

The project window has too much uniformity--at a quick glance everything looks the same.  It's all blue, black, and white.  Using color is one possibility.  Another is to create more pop by varying the fonts.  Maybe give classes a different, slightly larger font.  I'm less concerned about the specific solution than I am about having a solution.

2. The second issue is what I described earlier.  When I'm viewing something deep in the project hierarchy it's hard to know exactly where I am in that hierarchy.  I use class, library, and folder names to give context to chunks of code.  I know I'm looking at a DummyJoystick class and can infer it's part of a unit testing component, but which component is this particular DummyJoystick used to test?  That information is given by folder names higher up the tree.

In retrospect I don't think colors would help much with this problem.  I'd have to remember which color is associated with which library at every level of the hierarchy.  Those lines in the tree view look an awful lot like wires.  We can label wires... how about putting a vertical label on those with the name of the library the line is an extension of?

[tst]

> how about putting a vertical label on those with the name of the library the line is an extension of?

I already think there's too much noise there, and adding labels probably wouldn't help that (although, to be fair, I would need a screenshot to really tell). How about changing the wire thickness by how deep it is in the tree? This would only really hold out for a few levels before becoming unmanagable, but that should probably be enough. The problem with that is that the tree is probably a standard control which doesn't allow this.

Another alternative is to display the full hierarchy of the currently selected object (if there is only one selected) in an "address bar" or displaying it as the tooltip when you hover over it or displaying it in another optional column. That last option already exists for paths, so adding another for the hierarchy should be easy.

[Daklu]

>How about changing the wire thickness by how deep it is in the tree?

I already have a fairly good idea of how deep I am in the tree... the problem is that I don't know where I am.  The address bar wouldn't really work for me--my names tend to be longer and more descriptive than many and it would get cut off if the hierarchy were listed on a single line.

Maybe instead of having the parent nodes scroll off the top of the window, the parent node at each level always shown at the top of the window directly below its parent?  Hopefully these images help illustrate what I mean.  The first image shows a standard project explorer view.  The second image is after I have scrolled down a little.  Notice how the project context is lost.  The last image is in the same location as image 2, but with the "always show hierarchy" option.

[tst]

That's definitely an interesting solution, although I'm not sure how likely it is to be implemented considering this is also a non-standard behavior. The address bar can probably be made to have more than one line and could probably be made more readable if each level in the address was clearly separated somehow (e.g. if they alternated between bold and non-bold).

In any case, I'm voting for the idea now (so at least you have one vote 😉 ) because I agree that this is something which would benefit from some solution. I still doubt the original suggestion would help much, but something can still probably be done.

[Darren]

Any idea that has received less than 3 kudos within 3 years after posting will be automatically declined.