Any time I find myself doing the same thing with a set of components I make a small cluster but the issue I’m running into is that I find it difficult to find that cluster again. My suggestion is to provide a cluster library - maybe a side inspector that lists all the clusters in a project and you can search by name. Components are big in UI design software like Sketch, the idea is that you build up a design from user defined components rather than starting from scratch each time.
Is a beta of v2 of Grasshopper available? I’m curious to see what direction it’s going in. I find that Grasshopper generally handles most things I throw at it but I find it handles larger definitions less well. Are you working on a solutions to this problem?
Yeah, I’ve already asked a couple of times for a proper search engine. Both Rhino and GH need it. Hundreds or thousands of tools, and they force you to memorize their name or put it in minimally categorized groups. Apparently I was ignored, I think they spend much more time programming than using their software and then they don’t see all that is missing about the user experience.
Here at the right you can see that David has made a TreeView, but maybe it’s just a quick and easy way to keep tools at hand, and not something that will see the light. I don’t know. If this had access to folders and not just the loaded components, it could be quite interesting.
I wasn’t planning on keeping it, it’s just a stand-in for the tabbed panels which I haven’t written yet for GH2. Although we’re now using the treeview in-house to keep track of component and documentation review, so it’s unlikely I’ll ditch it entirely since it does serve a purpose which wouldn’t be covered by panels and tabs.
That’s true. I spend a lot more time developing than using, but I suspect the main issue here is that I really don’t want to sacrifice many hours doing something for GH1 which cannot be easily siphoned into the GH2 code-base. This is true for almost all UI code.
Having super-categories, or workspace layouts with good customisation would be great, but it’s about two months of work and two months of delayed GH2.
I don’t expect anything new for GH1, I prefer full focus on GH2. And I don’t expect hundreds of features either, but I do want the doors to be open. GH1 library is quite closed in the sense of using access modifiers that prevent third party developers from creating over it, both in classes and in methods that could be overwritten or called from outside… but by design we can’t extend functionality over the existing one, only replicate it with internal variations. I’ve always thought that, barring exceptions, this approach would do more harm than good.
In this particular case. You simply support metadata for the components. The category, the subcategory, the id, the name, the nickname, the description, the icon, example, author, plugin, date, license, alias, shortcut, documentation url… are metadata, and there could be many more, like object type, component/parameter type, utility, frequency of use, frequent inputs and outputs… etc, etc, that some can be customized and overwritten in each computer. And then it would be possible to create search engines or workspaces by third party developers, which is better than nothing, right? (measuring all this things would have a significant impact in other directions as well). Just leave some doors open this time you will have a solid and homogeneous core. Leave the community experiment and in the future make your own version by accumulating the experience of others. And everyone’s happy.
