Don’t know if there is an obvious way of doing this, but what I’m seeking is a kind of “collapsing” option for these pieces of a definition that you know already work properly and won’t need to be touched in like forever and are just occupying screen real state.
I know with clustering this could be kind of achieved, but I’m looking for a “cluster” that doesn’t need to be exploded but rather just to be “furled/unfurled” and whose copying doesn’t mean instantiation (that’s what clusters are for).
To sum up I’m kind of asking of a way to “layer” or “level” the construction of a GH definition in a way that going “inside” these modules would mean going a level “down”.
Groups occupy space also. They are good in terms of clarity and understanding and with Human, work wonders, but I’d like to encapsulate these parts of the definition like clusters do.
That sounds like a paradox to me. A copy of a component is a new instance… Perhaps you should explain more what you mean by this, and how it would be useful - copying without instantiating…
I think I got what he meant, I was also thinking of suggesting this. It is a kind of how Excel sheets work. You have tabs (sheets) and you can develop a whole another algorithm inside another sheet and get the result and use it in your original definition as a single component. It would be like Rhino workspaces, but it will all be stored inside the same GH file.
Currently as a workaround I use ghpython components with virtual components. That way I have more functionality than a cluster but save the space. However sometimes it is difficult to debug if you go back to it after a while and you’ve forgotten what you’ve done. I use a lot of comments inside these scripts.
So +1 from me this will be very useful.
Update:
Another example, see how XMind uses tabs, like a layer.
Instantiating occurs already in clusters. I want these “collapsible groups” to be independent from each other… or not. Perhaps an option with clone/copy…
Maybe the simplest implementation would be to have input and output components but acting like an off-sheet connection to another .gh file. you can have them both open and simply switch.
Perhaps the solution is using a small python script in one gh file saving the output to sticky with specific name, and another one in the 2nd gh file to take the sticky and provide the output. Unfortunately in order to update changes you’ll have to switch between the two gh files and recalculate. But this seems like a workaround.
I can’t see why Clusters wouldn’t do exactly what you want, except for maybe if they are slower to execute.
A cluster doesn’t have to be saved to disk, it can be unique, it can be saved only in the gh-file in which it was created, and so you would have this “lower level” which is shrinked/hidden, while also providing you with a means to peek into it, if need be. All this just to save space, no saving to disk, and no copying or instantiation assumed.
Single click switch between the “tabbed cluster” and the complete gh definition, this is the difference.
Currently you have to double click then you select to exit and you have to select from drop down menu if you wanna just return/save/discard. All that will be avoided and it is much simpler if you could just develop it multi-level (tabbed) since the very start.
Clusters can be kept as they are currently, to allow them to become UserObjects.
Tabbed multi-level concept will improve the UX.
This also provides better scalability of the definitions. You don’t search through the whole definition to find something you wanna use in your next project, you simply open its tab and copy all.
Tabbed cluster would still be… clusters. I really don’t see the point. A named Cluster adheres to the concept of “diagram” whereas a tab would separate the Cluster (part of the diagram) from… the diagram. Which is exactly what you don’t want to do with a diagram.
Groups and Clusters are genuine and diagram items in that they contribute to the diagram idea to graphically convey information - in the diagram - about what the diagram stands for. A tab, OTOH, is a UI-concept with no resemblance to a GH diagram.
Clicking on a Cluster is how you “drill down” and I tend to press CTRL-S (save) to back out of them. A dedicated keyboarkd command or a single “back out” button somewhere in the UI would perhaps be helpful, but Tabs? Not if I where the architect.
How do you print a diagram’s tabs so that it connectivity to the rest of the diagram is conveyed?
No way you can do that. Keep diagrams as diagrams, because the very idea with the concept of a diagram is… being a diagram.
@DavidRutten, have you ever thought of a component like the relay but if you click it to collapse/expand whatever is behind it I’d love to see how this will work.
Seems like you can just use Data Input and Data Output workflowand make different files for your operations. (Is a good way to keep GH files light also)
Lately I’m working on concepts like this, in the case of MetaGroup, is like a cluster but in the same document, it is possible to collapse (in a single comp.) or deploy the components, but is a nest of strange behaviours yet… I have come to this by trying to modularize the definitions to the point of creating a meta diagram (also with layers in mind), but there is still a lot of work to be done…
Is it something like that you mean?
On the left there is a canvas section component, which only scrolls horizontally, and the other is a group with options of style, title, description and image.
The drawback of culsters, compared to my idea, is that AFAIK if you duplicate a cluster and make changes to it, these changes affect all the instances of the cluster. And I want them to be independet, actually what I’m looking for is exactly this “metagroups” that @Dani_Abalde posted below.
TBH I did not know about this one, good hint, thanks.
)
I’d love to see how this will work.
