Drawbacks of the ribbon layout

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.

Replies to This Discussion

Permalink Reply by David Rutten on January 31, 2016 at 4:05pm

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.*

Permalink Reply by Ángel Linares on January 31, 2016 at 5:07pm

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.

Permalink Reply by David Rutten on February 4, 2016 at 11:42am

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.

Permalink Reply by mark zirinsky on January 31, 2016 at 7:01pm

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

Permalink Reply by David Rutten on February 4, 2016 at 11:38am

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:

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.
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.
Provide a more hierarchical interface to components. Which are important, which are esoteric, which are just plain weird...
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.

Permalink Reply by mark zirinsky on February 13, 2016 at 7:59pm

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.

Permalink Reply by David Rutten on February 14, 2016 at 5:56am

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

Permalink Reply by Christian Schmidts on February 14, 2016 at 6:49am

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?

Permalink Reply by Ángel Linares on February 3, 2016 at 6:56am

Mmm...it seams that the February plugin explosion is pointing to this problem in certain circles...:P (https://twitter.com/digitag/status/694603801622401025)

Permalink Reply by Anders Holden Deleuran on February 3, 2016 at 7:19am

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

Permalink Reply by len tak on June 28, 2017 at 3:30am

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.

Permalink Reply by David Rutten on June 28, 2017 at 7:12am

'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.