A complete UI overhaul of Rhino would be a much welcomed move

Yes they do. Many did and I’m not planning on going back and quoting everyone.
And having a Windows Forms-based paneling is just bad. It’s old and should be done better.

Talking about which design approach to take, well, that’s subjective, and I wouldn’t argue there. I’ll say ‘Go flat. It’s sharper, quieter and better’, but someone will say ‘No. Go full 3D. Pop everything out, make it scream’.

I would only like for us to agree that Rhino’s UI is old and rusty, and needs a change, and someone should look into that.

And for the fifth time - The behavior of the UI doesn’t need to change drastically. Rhino’s UI behaviour has some very good ideas behind it and I like it. If it was unusable to me, I wouldn’t use Rhino.
But the skin and the code behind it should be modernized.

I never said people are “narrow-minded”. Please don’t take my sentences out of context.
I said:

… talking about how different software packages are implementing ‘monochromatic’ design, because today UI designers are doing some amazing things. They are out there, you just need to look around, and appreciate the good work they are doing.

As someone said before - Building a new UI is not just “slapping-on” a new skin. It needs to be done through a scientific approach. Reviewing user data, and taking into consideration the wishes and needs of those users.
The design and the overall look is just a bi-product of it all.

How far are McNeel ready to take this, it’s up to them. Will it be just a revamped design over their existing GUI, or really go into improving some aspects of the behavior of their UI, I don’t know.
I would encourage them to go full-blown “Blender 2.8”, and rethink how different people use Rhino. But that’s just me.

In the end, something needs to be done. Rhino is lacking behind and it might hurt the users and the functionality of the software itself in the long run.

I checked out Blender 2.8 experimental build last night. I must say that it shows some serious thought has gone into creating and supporting different workflows. Compared to 2.5x-2.7x yet another huge step forward.

I think we can look at how different workflows are supported and see if we can learn from those, apply to Rhino.


(post withdrawn by author, will be automatically deleted in 24 hours unless flagged)

Personally, I found this comment offensive.
Never met TomTom, I’m sure he is a nice guy.

I haven’t used Blender recently, but I remember them trying to fit mouse buttons and user interaction to match that of different software. This is good idea. But I think difficult to reach with Rhino. Maybe just adding reordering of panels/toolbars/tabs will do, but if you try to change the mouse behavior this will be a nightmare.

(side note: I will hate to see you implementing the horrific mouse control of CATIA with all that hold-one-button-click the other to rotate, this is hell, work like this for hours then open a PDF and try to left+right click to zoom :smiley: :laughing:)

I haven’t used Rhino on a daily basis in nearly fifteen years. Bought my first computer 2 years before the PC came out. My first Cad program was Generic Cadd, then Visual Cadd the Windows version, followed by Rhino, AutoCad, Solid Edge, and currently SolidWorks.

So I remember Lotus 123 and WordPerfect too. 123 was one of the first adopters of icons and I use to use a printed ad they ran with icons all the way around the page as a test. I never found anyone that could identify more than about 30% of them. WordPerfect was a nearly perfect interface in many ways. On startup you had a completely blank screen with a blinking cursor in the upper left corner. All commands were on function key combinations which worked well but was difficult to master.

Now Generic Cadd used two key mnemonic combinations and no enter key. CO, MO, C2, C3, ST, RO, TX, LD, AD, LE, and so on. I’d bet that nearly everyone here can guess what those commands did, and it turns out that just 28 commands like that and you could really bang out the drawings. To this day I use those same shortcuts in AutoCad, Rhino, and SolidWorks.

I hide nearly all the toolbars and icons to give the biggest possible workspace. I hate the word “Intuitive”. Nothing is really intuitive, it is all connected to your environment. If you grew up in a place where there were no knobs to turn you would not think to turn a knob when you first see it. I prefer “Discoverable” If an icon or keystroke is pressed it should lead you to what it does and how it works.

Finally about 15 years ago I posted a comment on the Rhino user group that the perfect user interface is the one you don’t notice. I think that is still true today.


So next stop is the nursing home then?

Just fooling…sage insight, seriously.

However, the youngins need their dark modes and eye candy, lest they begin to twitch.


the new Dark Mode in Mojave OSX looking quite nice over on the Mac V6 WIP, hats off to McNeel for the work in utilising this :smile:


Yup, options are good…


Our engineering department has 50 years experience. Three engineers totaling 5 years, and 45 for me!


Agreed. I like the monochromatic icons in PS, but there’s such a wider toolset in Rhino, I’d be afraid of getting a little lost without the ability to introduce some color. If monochrome icons were ever introduced, it might be nice to have the option to tint them, either individually, or per toolbar/tab. I have a bunch of tabs across the top, and while I don’t typically use the scrollwheel to scroll through them, I have noticed lately I do tend to get to the “Select” toolbar tab that way (scrolling), because I know when all the icons turn yellow I’ve arrived…color can be a useful navigation aid at least…

Rhino differs from most of the here referenced packages - not sure if this is the correct term, but:

  • Rhino is Data-Oriented, insofar as functions (commands) run on the data (geometry) and there is no strong dependency on the concept of Objects.

  • Most vfx / animation (and many CAD) software is Object Oriented. Objects are encapsulated, can have hierarchies, names and complex interdependence (what Grasshopper introduced).

The reasons for this separation are quite interesting, but to stay on topic:

That is also the reason nearly all Commands in Rhino are ‘equal’: As icons you can have them all on the screen at the same time. There is very few Object-related data and commands. UV-mapping and materials come to mind. And they are out of place - hidden in the properties panel… because they go a bit against the concept of Rhino.

I would argue that therefore the complex hierarchies of UI-Design that are found in Blender, Maya, Max etc. are not applicable to Rhino.

Apart from a modernized UI in terms of graphical language, it would be interesting to hear what would be ideas for concepts that take this difference into account.


If i can say anything here… Well in my case command line is the most important part of Ul - without it my work would took ages im using icons when im looking for command which i just dont use on daily basis on top stripe menu im looking for things which can solve something when im stuck but i think it depends on user - in my csse 99% cmd line is primary way of input.

Hello - one of our developers points out that is is very possibly a case where Rhino is being paged while Windows thinks hard about your other ‘heavy duties’. 12 GB of RAM is not such a lot to be working with these days. If indeed Windows is sending Rhino to a page file, there is not a lot we can do to make it work faster. It may be worth looking at your resources when this happens, in Task Manager.



My 2-1/2 cents worth:

Back in the early days of AutoCAD, there was a HUGE effort to support individual developers and market solutions, not so much for the last 25 years or so …

Back then, one of the MOST POPULAR approaches was to group commands on the (then) Digitizer menu (the precursor to the on-screen icon movement in CAD) by their general function, with some of the most successful generally applying a base color inside the Icon (not the digitizer “square” but the icon elements themselves) to aid visual command differentiation . I NOW find the SAME COLOR-BASE in ALL Icons in RHINO to tend to negate the -generally- reasonable pic-choices for the command Icon itself, increasing running confusion by disaffecting command DIFFERENTIATION when moving to select the “next” command - reducing the effectiveness of the generally reasonable approach to ICONS-for-command-selection approach as it currently exists in RHINO.

If we started the UI refurbishment by color-coordinating commands that work similarly, for instance the ones we get in a fly-out Icon Bar for a parent Command Icon (to start with, maybe … ) , I think THAT would go a long way in the right direction. I have collected my FAVORITES in the pop-up for OSNAPS and have set that as my default pop-up when I press the center scroll-wheel button.

My OSNAPS icons still make up the top-row of the pop-up menu, with my other commands arranged by function below- within the popup.

This has eliminated more than 80% of my menu-searching for the next function I need - 1-click of the scroll-wheel, and I have the command I need right in front of me. If they were somehow color-coordinated, I couldn’t REASONABLY ask for more ! Well, maybe a small pop-up right next to the floating cursor arrow with command options so we don’t have to go away from the mouse to type in an option at the keyboard or go away from the working area to select an option at the Command: prompt …

Yes, we have the ability to FULLY CUSTOMIZE each and every ICON in the menu system, but this effort is generally more involved than most users are interested in or prepared for … . If someone were to work up a replacement ICON system for the CURRENT RHINO Menu system, I’d pay a nominal cost for something, and maybe even a bit more if there were strong indications that user feedback would be reasonably included in subsequent releases … .

You know, it seems REASONABLE to suspect that if someone were to make a bit of an effort to resurrect the old user-developer days of CAD and come up with a well executed UI “Skin” for RHINO, I bet it would get some real interest here ! What an interesting overlay plugin that would make ! SHOOT it might even prove to be the IDEAL “Custom Command” implementation portal environment, with a basic As-Is Commands Overlay Skin an opening starting point, with Grasshopper and similar CUSTOM Functions possibly a highlighted upgrade feature !

If NO ONE were interested in something like this, this thread wouldn’t exist ;=) !

All the VERY BEST to ALL from Texas -


1 Like

… or maybe adopt a more complete commitment to excellence … ;=) !

Yes, think UI today is lot more important specially because of the time that designer spend using the tools, but it’s a difficult endeavor to get right, for instances we have discuss about Overhaul and possible modifications, but no one has talk about what is the core UI design that makes Rhino works. For instances in this discussion we have criticize different parts of the UI, without focusing on what is that makes Rhino a great tool, what are characteristics that “we” desire to preserve. I’m in accordance with @cfee that UI change can only come from a plugin that the community receives with open arms similar to what happened with Grasshopper.

If only one could have G0, G1 or G2 locators with combs on boundaries between surfaces as one is building them or manipulating CPs…

1 Like

@ Lagom
??? ;=) !

Hello - please see

for at least a step in this direction.