Grasshopper detached properties "@"

Hi Speccool team!

After being using the gh connectors intensively later, I’d like to report my feedback on the detached properties, merely as user perspective.
90% of the time I do this mistake:

and 50% of the time I don’t recognize at first glance why my object doesn’t have the fuc**** attribute since I just assigned it!

Does anybody else doing this mistake every time?

Some arguments:

  1. The system is doing something behind the scene without telling me that. The property name is in fact changed

  2. should “detached” be the default?

  3. Instead of marking when a property is not detached, mark when is detached!
    Why not something like this:



Hey @iltabe, that’s good feedback there. We feel ya!

I think this

makes total sense. We were probably stuck in a loop when we did this, it makes much more sense that way 🙇🏻‍♂️

PS: Raised an issue so we keep track of it.


Hi all,

I agree that @iltabe’s suggestion makes more sense.
To add a thought, the Grasshopper client docs mention that

“All properties are detached by default for performance reasons”

I can understand that this is true for nested (Speckle) objects (typical example of reference type data), however is this performance gain still valid for value types (integers, strings, booleans, …)? Storing a numerical property as a reference seems to be overcomplicating things.

Perhaps the “@ / detach” mark is not selected by default, but automatically appears when connecting other Speckle objects as input (but can of course still be manually overwritten)?



Hi @kelvin! primitive types don’t get detached. So if you flag an int/double/bool/etc. prop as detachable… core won’t detach it, as it doesn’t make sense as you say. Strings either, but they probably should be chunkable (different story).


Thanks for the clarification @dimitrie. From a user perspective I would say that this backs up the change suggestion above: default detachment (even when connecting primitive types) is definitely misleading.

1 Like

Thanks for the suggestion @kelvin I’ve updated the docs to clarify the behavior!
@AlanRynne do you think it’d be possible to have it toggle automatically when the input port is connected, based on its type?

1 Like

Hi there!

This is a cool suggestion, although it’s tricky…

The main problem I see with this approach is that we have no real control over what the user is going to plug into each input. It can be a single number, or a huge DataTree with a mixed bag of types (like meshes, breps, numbers and text all together).

Imagine this, but 10 times worse:

So this would only work if the data is properly organised by type, which in an ideal world you would do to keep your sanity, but you don’t really have to using Speckle. It’s totally up to the end user.
I’m happy to be convinced otherwise anyway :smiley:

On a side note, we’ll be adding the original suggestion from @iltabe on the next release. Here’s a quick sneak peek :eyes: