Feature added to Grasshopper?

In the 8.12 Service Release changelog it is mentioned that a feature is added to better show component input types (Item, List, Tree). However, I don’t see anything different. Should there be something?

@brian ?

Features Added:

  • Grasshopper: One of the most common problems with GH that I see when I teach it… (RH-37737 )

Hi Tuomas -

It doesn’t look like that, no. The issue was on Andres’ list to provide more information for more than 7 years and was then simply closed. The rest were automated workflows. I suppose the issue should have been set to “Obsolete” or “Won’t Fix”…
-wim

Ok thanks. I was silently hoping for something like dashed grips in the component inputs and outputs to represent Trees or something. I don’t even know if that would useful. Maybe GH2 then.

“…Most of the time, Rhino and GH freeze because you connect a large list with a large tree when you’re not supposed to do so…”

… that moment when you release the LMB and that instant recognition you just messed up :face_with_symbols_over_mouth:

I’m not a UI designer, but here are some obvious suggestions for UI improvements in Grasshopper to clearly signal whether a component output contains an item, list, or tree.

  1. Color-coded Grips: Use color coding for the output grips: green for items, yellow for lists, and red for trees. This quick visual cue would give users an immediate sense of the data structure at a glance without needing to hover.
  2. Shape Indicators: Different grip shapes for each data type could also work well—circles for items, squares for lists, and triangles for trees.
  3. Textual Suffixes: Adding a suffix or supper- or subscript to the parameter name, such as (I), (L), or (T), for item, list, and tree, respectively, could be useful. Alternatively, brackets around the name could subtly indicate if a data structure is present.
  4. Icon Visualization: A small, inline icon near the output grip, such as a single dot, a connected line of dots, or a branching tree diagram, could be subtle but effective.

While this could improve visual communication, most of the time, you’re on auto-pilot and don’t stop to think about data structure. It’s carelessness that causes the freezes. A better solution might be a check on input—like an alert when something’s connected in a way that requires over 10M calculations or so.

Even better, as already suggested by others in the past a **loading bar"" visualizer to know the status of an operation, or god forbid a working ESC key to stop execution instantly when something’s wired wrong would be a game-changer for catching these issues before they freeze everything.

3 Likes

Good suggestions!

I once heard of a man, who had heard of a person, whose grandson’s niece learned about a guy who had actually pressed Esc and got the graft-bomb defused!

"…like that moment, what, back in 2007 or so, when @DavidRutten is testing out GH v0.01, just casually grafts two trees together, freezes Rhino, and thinks to himself, ‘Yeah… I should probably fix that.’ :wink: