Hidden wires should be ignored now for relay-double-clicking. Does your ‘unintentional’ mean that you did double-click on a visible wire but you meant for the double click to bring up the search box?
Yes that is the case. Sometimes I have portions of the patch with hardly any “free” space left for bringing up the search box. in my opinion the double clicking for relays should be accompanied by an additional key like “shift” .
Seconded
You don’t feel there might be deeper problems with a file by the time there’s no empty space left to click?
ps. Incidentally Space brings up the search box as well
you might be right.. or they just follow a higher ordering system.. 
but seriously when talking about my wiring habits, i have to say that i don’t use hidden wires, groupes, relays at all because they makes the patch rather less than more readable for me.
the only structuring system i found joy in is the approach of the telepathy plugin, where you also can name frequently used data streams and get them by name like a variable, search and replace, etc
So my humble suggestion for grasshopper 2 would be to have something like that, but even tighter integrated, meaning that you can search for these once in a sender component defined data streams with a prefix like eg “#” by their name directly in the search box and get the corresponding receiver.
@DavidRutten So how about a Gh2 relay that supports hidden wire and the same cool features of telepathy?
i.e. connect by key search and popup shortcuts.
I think that would be pretty awesome!
I don’t plan to have any wire display options in Grasshopper 2. All wires will be drawn in fancy mode and you can’t hide complexity by not drawing it. Instead I want to make it easier to genuinely remove complexity.
There will be ‘globals’ which are values that are accessible by name, but it’s not clear yet whether that will only apply to single values such as sliders or any old data anywhere.
You’ll be able to use hooks to get data from one file into another, to get data into and out of clusters (just as it works now), and presumably it will also work within a single file. I think that’s roughly how telepathy works right?
I don’t mind that. Sometimes its nice to to group all parameters and controls in on the top-left side of the canvas. That’s where wires could really become a bit messy
I guess a better integration of control tools on rhino grasshopper panel would alleviate this issue.
I wouldn’t quite describe telepathy like that. It’s more like a smart way of automating wiring from different points of a script… this quick video is the best way to get the idea:
https://player.vimeo.com/video/236864277
[Edit: added the text “unless both ends are visible at the same time” here and there to clarify.]
That’s bad. Really bad. Wires are by no means always the best way to convey logic. At some point you will need to know the exact connections, but often named parameters is the only thing that actually helps understanding a certain complexity.
Let me give an example, but before showing it, I should point out that the most “robust” way of conveying connections is by “role names”, which is used in UML diagrams. A role name is essentially the same thing as a pointer-.property in C#, like for instance ([Class] inside square brackets)
[Person].homeAddress [Address]
… meaning, “from a class Person-dot-homeAddress the property homeadress points to an instance of an Address class”.
Although this is not always meaningful in an Instance Diagram which a GH definition actually is (as opposed to a UML Class Diagram) it still has its use also in instance diagrams.
Now, consider the following case, where a MinimalBoundingBox gets deconstructed into directions aligned with WorldXY directions (if within 45º of respective WorldXY axis) where all directions are assigned domain specific names (so called “DSL”) which in this case is the medical terms used for directions with respect to the human body:
Fig 1. Translation of indexes from a home brewed “DeconstructBrep” to the DSL terms, and it’s corresponding WorldXY axis (given that the body part is on either side of X = 0)
This approach to identifying data, or the true meaning of wires if you wish, is in turn reflected like so in the GH diagram:
Fig 2. Wires, if any, starts from here - with a name! (named parameter) - which is essentially a “role name”, where an index is translated into a meaningful direction name:
But, why are there no wires going out from these named parameters? Well there are, but they are hidden, and should be so (and I’ll explain why in a bit). But you can imagine the messy diagram if all these wires criss crossed the canvas:
Fig 2b: Messy wires, if displayed:
It’s because IN THIS CASE a wire will only make a mess and will not add any meaning or readability to the diagram [unless both ends are visible at the same time]. Look at this - no wires from the Deconstruct & ListItem Index components!
Fig 3. See the question marks - no outgoing wires:
The reason why there’s no outgoing wires is, as I already indicated, because they add no readability to the diagram [when both ends are NOT visible at the same time]. Look at this mess when I select the named parameters (which actually has outgoing wires, but they are hidden):
Fig 4. Displaying a complete mess of wires adding little or no readability or meaning to the overall diagram:
OK, but where then is the “meaning” and the “readability” placed in this diagram?
As you would have guessed by now - the meaning and readability of the wire connections are made crystal clear in each (other) end of the wires! This is done by using the “role names” concept with named parameters in both ends of the wires while the wires them self are hidden, and always SHOULD be hidden [unless both ends are visible at the same time] (which is the only useful way IN THIS CASE):
Fig 5. The “other end” of the hidden wires explain why visible wires wouldn’t add anything (not anything really, [unless both ends are visible at the same time]) to the readability and understandability of the connections - only directions matters, which is reflected in the “role names”, like so:
Notice how the wires are hidden. And if the source-end of the wires where the only “info” when reading this diagram, how would you know - far away from the source - what direction you are dealing with? A wire would add exactly zero information, because it’s general lack of “meaning” [unless both ends are visible at the same time] and since the very distant source component isn’t visible, you have no clue unless you scroll over the diagram back and fourth like a … [insert derogatory epithet here].
Wires must be able to be hidden, and Fainted is yet another state in which I usually convey that those wires are “less important”, like when used for connecting “debug components” or “display components”.
SUMMARY
All in all, removing multiple levels of the wire visibility doesn’t help reducing complexity, instead it prevents reducing complexity and readability and understandability.
And it would make things very bad in some cases like this where only NAMED wire ends actually makes sense (the names are the only thing that guides the developer to connect the correct directions, and same thing for the reader).
Please don’t make a complete mess of GH 2.0 diagrams.
// Rolf
… instead add the same functionality to the (typed) parameters as exist in the Relays. Relays works as they should, but, there’s a serious performance problem with them (especially for lists, probably due to type checking). But Parameters a good (in many ways) but lacks the copy-downstream and append-by-clicking functionality of the Relays. Enhance the parameters to the level of Relays, and that will be super good!
// Rolf
Hi Rolf,
I would suggest that the mess of wires does convey information: it points you to where your outputs are consumed, you can see where you need to check for side effects without looking in detail at the whole model, you can see whether you have a simple or complex interface. You may see that the model would be better understood if reorganised on the page.
I definitely prefer fainter lines though. And I’d like better avoidance of components. Or wires that get fainter when passing under a component so they’re not mistaken for connections. And as a new idea, how about equivalents of the colour coded wires and spiral wrap used in wiring looms. Possibly satisfying both of us.
As a newcomer to Grasshopper I’m finding clustering the best way to reduce diagram complexity (when you learnt UML - or one of its predecessors - I’ll bet you too were taught the 7 ± 2 objects per page rule). Better synchronisation of the interface names between the detailed view and the abstracted view would put icing on the cake.
Cheers
Jeremy
This is correct only when you see both ends at the same time. In Fig 5 you see how I use fully visible wires in a Group where both wire ends are visible at the same time.
The hidden wire state, with named parameters in both ends, is what makes a widespread diagram readable, as show in this specific case. Without being able to hide the wires the diagram would only be a cluttered mess.
So what I am saying is that the existing three wire visibility modes really are useful, and for some cases (like in the use case shown above) it would destroy GH to remove what’s already in there.
Your other suggestions may be of value as well, but the “role name” concept is the most generic concept ever invented and is sometimes the only way to make a diagramming tool useful.
UML diagrams for example rely 100% on “role names” for links/wires. In part because a diagram can be split into different diagrams and so you will never see the “source” end of a link, aso aso. and in such cases the wires/links are, again, completely meaningless (without “role names” at the relation ends).
Again, only when both ends are visible wires/links can convey information.
But in a big GH diagram you would zoom out so far that components or parameters are not readable anymore, and then you’re back on square zero again - no useful information available, only a mess of wires going criss-cross all over the canvas only obscuring other things.
All existing modes are really useful and should not be removed.
// Rolf
We’ll have to disagree here.
Where I don’t disagree is that they should keep what you see as an important aspect of the GH UI. And I’d like it to be more flexible, not less, so it works well for both of us.
Jeremy
It’s pretty close to what I had in mind with the hooks, except hooks won’t ever show wires since they might point to a different file altogether.
The wildcard naming is a good idea though.
I know they’re not, but if you have a wire I don’t see the benefit of pretending you don’t. Which is what hidden (and to a lesser degree faint) wire options do now. I don’t want to get rid of the spaghetti by closing my eyes and shouting “I CAN’T SEE YOU!”. I want to get rid of it by offering a wireless alternative. That may be by having named hooks which share data, or by having data write/read components, or by declaring globals, or…
Hi @DavidRutten,
Rolf isn’t shutting his eyes and pretending they ain’t there. He’s filtering out noise.
That’s helpful.
Regards
Jeremy
You have two different major cases in which you read wires differently
-
When reading the GH diagram (overview to understand the structure & logic)
-
When designing the diagram.
About this I would say:
2, When designing the diagram it makes perfect sense to select a component and follow a HIDDEN wire from a distance component (to check if it is connected as desired).
1, But in many (most?) other cases (when both end components are visible at the same time) it usually makes most sense to show the wire in full.
§1 and §2 means - yes, wires are always useful, but full visibility is not always useful (at design time always visible yes, at other times, not always, only on demand, as it currently works).
So of course wires should always be there. Only (optionally) not always visible. Current solution is very good in this respect.
Is “named hooks” similar to what I called named “roles” (parameters with names on them)?.
// Rolf
But why is there noise in the first place?
I mean, I know why in GH1, there aren’t exactly many alternatives. My point was that my first angle of attack for GH2 is to get rid of the noise. I am not (yet) interested in developing better noise-cancelling headphones.
I think so. Very close at least. You use hooks already in GH1 to get data into and out of clusters. There’s no reason they wouldn’t work similarly within files, and horizontally across files.
Furthermore there will be global values that you can access by name as well. Big benefit of globals is that you can even use them in expressions. Downside is that because of this in-expression referencing a global can only be a single value, not a list or tree.
It about gradient quantity - few targets, visible wires Ok. But when having “to many targets” of a source value then visible wires no longer is efficient since it clutters more than clarifies while named roles plays the clarification role better in (many) such cases. The connection itself ( awire) must have a UI for designtime though. A wire, that is.
When in the business of headphones there’s no way you can ignore noise-cancelling altogether. When making sounds, a volume button would seem useful for reducing “too much” of whatever sound you’re producing. And so on.
Wires work very good as it is (supporting different “paradigms”), don’t destroy them, I’d rather see you enhance them.
// Rolf