Grasshopper component UI naming rules

Hello forum,

I’m currently working on a plugin translation and I’m trying my best in keeping the feel of it as “native” as much as possible.

By “native” I mean the feel as if it was always there. I like plugins that are consistent with “vanilla” grasshopper, which include native icon style and proper component/input/output naming. I got used to it and it makes more sense to me, because there seems a distinct style of naming stuff in grasshopper, however under a closer look I noticed some inconsistencies. My goal is to translate it in a way that is easy to understand by our multinational community. And even though original approach has words like parameter, flatten, graft, cull and so on, and these are hard to comprehend from the beginning, later you just learn to appreciate them and don’t think too much about them. Until you start to translate from another language and realize that some English names are kinda inconsistent (or, possible, I don’t get it) and sometimes fails to provide strong sense.

I would like to dig deeper and figure out what’s what and hopefully learn arcane art of good component naming.

When trying to find the pattern:

- "Ok, small i is for indices, cool."

- "Erm…, ok…, not always. I guess they are small on the right and capital on the left, makes sense!"

- "What?! Small on the left?! There must be another reason, I should dig deeper!"

Another Example:

Delete vertices vs Cull vertices (not how they do it, but is there a meaning behind the word choice)

Yup, the naming scheme is a total mess. It evolved slowly over time without anyone enforcing any sort of consistent rules. We have a professional linguist on staff now who is already digging through GH1 to find all problems and whose job it will be to come up with strict naming conventions for GH2. Everything from parameter abbreviations to jargon to tooltip sentences to data notation will have to be written down somewhere before the first alpha of GH2 goes out the door.

Yes, [Cull Index] removes/deletes the items at the given indices. It’s another example of a poor vocabulary decision.

ps. It’s good to see a post like this, people don’t complain enough about this type of bug. And yes, I do consider it to be a bug.


Thanks, David.

Not being picky or anything, it was somewhat cool until I started translating. Great to know that GH2 will be more strict about it as I will try my best to join developers’ camp and make something for GH/GH2.

Taking chance, would like to ask if there is a significant change in rhino commons in v6 and overall wouldn’t it it be a bad time to learn it any time soon (within a year perhaps)?

I don’t foresee any major changes in RhinoCommon, it’s a .NET style SDK so unless Microsoft drastically changes the .NET rules(very unlikely, bordering on nah-ah) it’ll just see incremental updates.

There probably will be plenty of cases where parts of the SDK will be marked as obsolete and replaced by different classes/methods, but that’s typically not something that severely hinders learning curves.

GH2 will be completely different from GH1 on the SDK level.

I see. Thanks, David, it helps me with priorities in a way.