Because I do write a program, here and there, I like commenting my work. I wish we had a view mode that used the icons and a name.
Grasshopper is great! So, much so, I do want tighter integration, such as a common color picker, similar icons. Grasshopper’s a keeper!
Is sunglasses what you are after?
That is very close, but for me, if the text/legend was on the component, it would be quicker because my brain would more easily accept the legend and component as one idea.
Currently, I am making groups of one, which is not good.
Thank you.
if the text/legend was on the component, it would be quicker
So you don’t want sunglasses, you want contact lenses…
So, this represents the average level of comments I am doing now. I should do more, but as they are, it’s a bit cumbersome to group singletons.
If I used Sunglasses, and then it wasn’t installed or not available, what would happen to the names?
I guess that the only reason why I stuck with the names instead of the icon view–is because that is what the default is. I am going to do experiments between icon and text. Often I don’t want to switch from narrative to graphical brain-space in Rhino, but Grasshopper seems more like programming than drawing, though many people use the icon view.
Perhaps I may mock up an icon with a text box on it. It would seem that how Grasshopper uses the bottoms of the icons for contextual-choices/twittles, might be applied to the top?
The issue I have with Sunglasses is that the text is not any part of an icon. Over the years, I have used a lot of types of software, and I put some effort into seeing how people see.
I would still like to see more Grasshopper integration, same window chrome/widgets, common color picker too. The result would be a smaller code base, but more importantly, when people see Grasshopper, they will see Rhino. I would like to have a Grasshopper window, like any other Rhino view; that would be hot!
Regardless, Grasshopper is a great and powerful too!
Have you considered renaming component inputs and outputs to clarify what is happening?
Yes, I have. That would slow my effort.
Very few things are on my Grasshopper wish list, but a better way to document work is one of them. I would still like an icon view, with the ability to label the component, like a little posti-it in function, but not exceeding the boundary of the component.
And grouping single components only to add a label doesn’t (slow your effort)? That’s how Binoculars works, with invisible groups.
Am I not here, on this forum, discussing the possibility of something better than grouping singletons?
As a retired life-long programmer, my experience is that comments become useless when the code changes and the comments don’t get updated. So clear code is better than “well-commented” code.
Noted.
I update my comments. As far as style, it’s a matter of style.
What would be helpful is the ability to add a comment to a component, that’s attached to the component, and visually shows that same connection.
Like labeling (renaming) inputs and outputs… 
P.S. Early in my GH experience, I tried renaming components to indicate their role in my models and quickly learned that was a disaster. I don’t use icons so could no longer tell at a glance what each component’s GH function was. Oops! Renaming component inputs and outputs doesn’t suffer that flaw. I use different colors on groups of components (with text labels) to organize my code.
The all gray image you posted with so many “comments” doesn’t work for me at all.
No, I am not interested in renaming component ports. In fact, I am strongly against it. I feel it’s a waste of time to rote learn what the ports are–only to have to relearn them because you have overloaded them.
Why is it that you would make a stand for a feature that would not hurt you, not one bit?
That is a very strong requirement and just because of space problems, I don’t think this can happen.
You could force a Message via code to components… Of course not suitable for components that already provide one… Once added you can remove the connection.
I work in icon mode and NEVER rename any input/output. What I do is add parameters when an important object/step is reached and rename that. But I see on your screenshot above you already do that. Yes, this is tedious to do on large definitions, but for me it’s the easiest to read.
There is MetaHopper’s Best Practicizer that can help for this thing.
Because most of GH native components do elementary things, I don’t find it useful to comment what they do, but rather what piece of the project comes out of them. It is however useful to label groups of components that together achieve a specific thing. I use GroupDisplay for the name to be visible when zoomed out, but Sunglasses (which I just added because I find it awesome even I don’t have the use of it) also has this option.
MessageComponent.gh (6.6 KB)
Here is some wisdom. This morning, they were printed on my teabags :
Hope this works for you…
I had no idea this feature was implemented 5+ years ago:
I’ve often wished for this myself. Seems I’m not alone in renaming component outputs and inputs.
If there is a tack-on thing on the bottom of the component, there could just as well be one on the side.
As a thought experiment: swap Grasshopper files between yourselves, or open a file you haven’t worked on in at least 6 months.
Do you think I haven’t done that? My suggestion is based on long experience. It’s good advice. The enhancement to propagate output names to inputs makes it even better, done 5+ years ago.
You can always hover the mouse over renamed inputs and outputs to see their original names.
You’re certainly not alone in this. I can’t imagine not naming the inputs and outputs of every component I add to the script.
I’ve just discovered that the automatic nickname wire dragging trick is Windows-only and I’m trying to switch over to GH-Mac. 
