I don’t know if this feature has already been requested, but like Rhino, it would be nice to be able to group the components in this way. It speeds up the search, makes it more user-friendly and allows you to add variations in functionality without hesitation.
Thanks for considering it.
I did miss it. Certainly some ideas are needed to reduce the initial shockwave of components, especially when you have all the plug-ins under the sun installed as some people do.
My point was to allow me to add different implementations of functionalities, similar components, without having to bother having them on the components ribbon.
But about the loading time, I wonder, Rhinocommon.dll and grasshopper.dll are loaded only once or for every .gha? I guess you’ve already considered this (like the subject of the post) but you know, just in case!
RhinoCommon is loaded before Grasshopper, Grasshopper is loaded before any gh plug-ins. You can’t load an assembly more than once into an AppDomain, so by necessity it’s efficient.
One possible improvement is that GHA could be delayed-loaded. Their icons and such could be cached but the actual loading of the plugin could be post-poned until the first time it is needed. However given that GH2 plugins can provide way more functionality than just components, it may be difficult to figure out exactly when they are first needed.
The idea of the Ribbon Layout Editor of GH1 should also be taken into account here. The YAK manifest could include a tag that allows you to group the plugins by family (physics (which includes Kangaroo and others perhaps), Architecture, Analysis for architecture, jewelry, mesh editing…), for example, WeaverBird, MeshEdit, MeshTools and Mesh(+) are tagged in “Mesh editing”, and a Ribbon Layout manager allows you to download and/or load them, always with the option to pick one from here and one from there, ie, customizable. That is, manage the workspace by choosing the plugins according to the task you need to perform. It’s a very inclusive feature for plugin developers, which is too far away from McNeel from my point of view. If you don’t orbit around McNeel daily, it’s difficult to know all the plugins that might help, so finding them from GH by family/tag/category would be nice.
It seems quite complex to solve the problem of initial load, so a component manager sounds reasonable. However, it would be a nuisance to have to deal with this if the initial loading time is not a problem for one. For me it’s not a problem because I solve it by having only those plugins I use frequently installed, so I hope the solution to this doesn’t raise new problems.
GH for me is like a toy box, very cool but very chaotic, and having the option to choose the workspace would offer a more understandable user experience. The regular user I think is a specialized designer, not a generalist, but GH is generalist. For example, an architect who discovers GH today (not counting the external influence) will only be able to know the surface area of what GH can bring to his or her work, but with a workspace manager he or she can easily add specific functionality and even access sample files to perform tasks of that field.
For practical help, I’d like to set up the following workspaces (component templates loaded): for common use (where I include the plugins I normally use), one for a more experimental approach (with random plugins I rarely use), and one for using documents that contain plugins that the rest of the world uses but I don’t use. It’s been years since I’ve tried this feature of GH1, but I seem to remember that it had some severe fail. And on the other hand, be able to access the workspaces that could be in YAK to meet the needs of specific projects.
Apart from this non fundamental idea, it would be nice for me to be able to choose which plugins to load at the start via user preferences (something related is included in GH1, but I’ve never touched it because I don’t understand it), and in case of needing it later, to load another one via right click on the tab bar of the components ribbon.
I can think of widgets, user controls… any new features for GH2?
Type assistants and type conversions mostly. In GH1 that didn’t matter because all you could do was provide functionality and conversions involving your own types, but now that’s possible for all types.
However it would be reasonably trivial to detect when a plugin does this for some type it does not own, and those special few plugins then just become load-on-startup automatically.
Modifications to the GH interface however (added menu items etc.) are much harder to detect.