Hi jonah,

> Also I would like someone to point me to a truly good
> example of overbloating, something other than the huge
> # of available commands.

Why would you need any example other than that?

Having a huge number of commands and trying to expose them all in a conventional toolbar + menu UI is precisely what leads to the appearance of complexity or "bloat".

It's a pretty simple consequence - if you have a menu that lists 100 things in it, it becomes harder to scan through all those things to find the particular one that you are looking for.

Certainly there are some users such as yourself that do not mind having a "huge list o' stuff" kind of UI but for most other people that is where the "bloat" kind of perception comes into effect.


> The discussion has come up many times and there are always
> good reasons why the seperate commands should remain in
> place.

There is really only one primary reason and it has to do with limitations in Rhino's selection mechanism.

When I initially designed Rhino's selection and command flow structure, it was only focused on working on whole objects. That's because the initial commands that I got working were things that worked on whole objects like booleans.

When it came time to work on commands that dealt with sub-objects, I did not really have anything set up in the "pre-pick" selection stage that could address that, so I decided to make a filtering system but make the filtering controlled by individual commands so they could automatically set the selection filter to what that command needed.

That decision had some consequences, it meant that commands in Rhino needed to be separated out into smaller individual commands that could each set the particular selection filter that it needed. I did not really have a problem with that because at the time it seemed logical to try and break things down into different pieces and then try to keep each of those individual pieces streamlined and simple. What I did not consider so much is that it forces some complexity (in a high number of commands) to be pushed up to the very top level of the UI where it impacts everything.

That problem did not really become apparent until much later on when more and more commands began accumulating. Of course, once you have a lot of stuff working in a certain way it becomes really hard to "turn on a dime" and it is difficult to go back and try to change fundamentals.


Also one other part that ended up being bad about relying on commands to set sub-object selection filtering is that it leads to a kind of messy inconsistency in how different commands work. Some of them are able to use the more common "noun, verb" type structure where you can select objects first and then run the command to act on them. But ones that needed sub-objects had to pick things after the command was launched instead, leading to a kind of non-uniform behavior.


When I set out to design MoI, I really wanted to learn from these mistakes and address some of the fundamental design flaws that I had inadvertently baked into the core of Rhino.

Having a selection system that would more naturally allow for pre-picking sub-objects such as edges or faces of a solid was one of the major foundational improvements that allows MoI to have commands that combine more functionality into them which helps to keep the UI much more simplified.


There are quite a few other areas similar to this where MoI is set up specifically to address a design flaw in Rhino.


> If the claim of overbloating has to do with the UI, it's well
> known that Rhino V5 will have a new one. Not sure what
> that will look like but it's happening.

That definitely sounds interesting! Do you have any information or screenshots that show how it will be set up?

Like I mentioned previously, it becomes difficult to change things once there are a lot of pieces that are depending on how existing things work. There's not only a lot of commands in Rhino itself but also a kind of whole ecosystem with other company's plug-ins that also depend on how things currently work. All of that tends to create a kind of inertia where there is a lot of pressure to avoid large overhauls of fundamental stuff like the UI.

So don't be too surprised if any improvements in Rhino are more of a cosmetic nature rather than a fundamental re-work.

- Michael