algorithmic modeling for Rhino

Due to the high amount of nice plugins that were developed during the last years it gets more and more difficult to find the right component.

I know the ribbon layout was implemented to organize your components in a custom way. It works well and intuitive in general but it has two drawbacks which make it unusable in my day to day work. 

1. It doesn't support user components and therefor plugins that consist of them.

2. There is no way (at least non that I'm aware of) to get the components from a newly installed .gha into an existing layout. Which means remaking the layout each time i want to try out a new plugin. 

Views: 1492

Replies to This Discussion

Yup, it totally blows. It was designed initially with teachers in mind, who wish to only expose their students to a very reduced set of components needed for specific lectures. I.e. it was never meant to be a customization tool, but rather a masking tool.

I do not have good ideas yet about how to solve the death-by-tab problem, but I do suspect that the best way to customize the tabs is to simply use typed commands stored in a textfile. Something along the lines of:

Hide Curve.Util.*

Hide Surface.Analysis.*

Hide Kangaroo.*

Rename Transform.* XForm.*

This would allow for a customised layout which still accepts new components. Or, to mimic the current functionality:

Hide *

Show Params.*

Show Curve.Primitive.*

Show Math.*

And what about the Rhino approach? Tabs under certain components, clustering functional groups under key components in more general tabs...I mean, building another clustering step trying to simplify what today are tabs into components icons. In that way you can hide a tab and anyway have access to it through long-click or whatever...

This topic is really interesting to me...anchoring here.

And what about the Rhino approach? Tabs under certain components, clustering functional groups under key components in more general tabs...


I absolutely loathe toolbar buttons that require a delay (either hover or mouse-down) before they pop out, but having 'special' buttons that pop out immediately akin to submenus might be a good solution.

Yes, I have been noticing this too. I have the same issue, too many tabs. Well, how about 'drag and drop' organization?  Allows user to move components from one tab to another. Perhaps the 'drag and drop' organizer acts as a front end to issue the text commands you mentioned 

Draw+Drop can be just a front-end to a bunch of layout commands:

Move Curve.Util.* To Geometry.Curves.*

Or perhaps:

Merge Curve.Util.* Surface.Util.* Mesh.Util.* With Util.*

The problem with define-a-custom-layout from scratch (something that both Rhino and GH do at the moment) is always that when new buttons are added they do not fit into the layout. I'm hopeful that a modify-the-default-layout will not suffer from the same problem.

To be clear, I actually think there's 4 problems here which all need different solutions:

  1. Reduce the number of components/panels/tabs on the main UI. Either because you do not want to expose new students to too much chaos or because you simply need the space.
  2. Ability to access components relatively easily, even if they are not currently on screen. This could be because they are on a tab which is not active, because they are on the dropdown of a panel, or even because they may have been hidden from the UI entirely.
  3. Provide a more hierarchical interface to components. Which are important, which are esoteric, which are just plain weird...
  4. Just too many damn tabs when a lot of plugins are loaded.

The current solutions (i.e. (1) Layout Editor, (2) Popup Search, and (3) Panel Dropdowns respectively) fall short and need to be improved.

I do not have a good automatic solution for (4) yet, though perhaps putting plugin icons on the toolbars and providing all plugin components through those will work. I don't know.

I just discovered the ribbon layout editor. my bad. And you know, it does allow drag and drop, so I have cleaned up my layout - moved the new explosion of components to places I can find them easily. So i retract my comment- you have already thought of it, apologize for my ignorance.

Yeah it exists, but it's a terrible solution to a pressing problem.

Hello David + All,

Even if designed with a slightly different aim in mind I think most of the functionality is there and working very well.

The suport of user object shouldn't be impossible. 

And for new installed plugins wouldn't it be feasible to append their tabs to the existing current layout as a last tab or just in the way it is now without the ribbon layout - just add them wherever they are specified to go. Also layouts could be handelt internally as transferring them from on machine to the other doesn't really add much value in my opinion. 

Then one could just edit the layout quickly if needed. I think that would already solve the layout problem for most people or am i missing something? seams that the February plugin explosion is pointing to this problem in certain circles...:P (

Paging Dr Heumann, 10 CC's of MetaHopper STAT!!

on a related note:

this is nowhere near a big deal, but is there a way (other than moving the gha files out of the components folder) to supress certain installed plugins from loading, much like in the rhino plugin manager? i have a fair share of plugins that get rarely used, and deactivating them would make loading GH snappier again.

i did try locking them in preferences/solver/plugin loading, but merely to the effect of getting multiple manual prompts while loading GH, which makes affairs even slower.

'fraid not. You can put all those plugins in a separate folder and add it to the GrasshopperDeveloperSettings load option. Then either change the options or rename the directory. It would require a restart, but then I think you don't mind that.






  • Add Photos
  • View All


  • Add Videos
  • View All

© 2021   Created by Scott Davidson.   Powered by

Badges  |  Report an Issue  |  Terms of Service