Working with Default + Custom toolbars is a complete nightmare. We need a fix

Hi RMA team,

This has been bugging me for a few years for now. I’ve come here for help and followed all the advice I’ve received, and the workarounds that I can, and I still cannot find a solution that easy to live with.

I’ve spend a lot of time to capture as well as I could the entire problem. Tesha took me a few hours of work, so please take a close look at it.

Let me explain the problem:

You McNeel, create default toolbars, and any new tools you build (like during the WIP) show up in updates every once in a while in these default.rui files, in theory…

…In practice, many times these new tools/buttons do not show up, so your workaround for that is having us run _ResetToolbars. Which is a very destructive command since it will manage to force bringing-in all your updates to the toolbars, by also wiping out all my updates to such toolbars. I should not be making updates/changes to default you might think… well, you kind of force me to do it. Let me explain more.

I want to see, and use all your updates, but I also have more advanced work to do, and for that I need my own toolbars/tools (many of them created by your super supportive team or the amazing folks in this community). So I have custom variants to toolbars like ‘Main’ (called G_Main) and ‘Standard’ (called G_Standard), but I still need to be able to see your ‘Main’ and your ‘Standard’ toolbars. Why? Because I work with a team, I need to show/teach them things sometimes, so I have to go to ‘default mode’, to make sure that I show things are in a familiar environment. This is the same problem any team lead, educator, trainer, support person would also have. So this is not a weird edge case. This is a very common case for any power user who socializes such power usage.

Let me build up how the problems start…

Step 1. As long as I keep all my tools in different parts of the screen from your tools, it’s all good> Like here:

Step 2. Let the trouble start. Now to be able to collocate my G_Main and my G_Standard in the same screen space/group of tabs as the default tools, Rhino actually makes disassociated/unlinked copies of those toolbars. Or what I called ‘unsecured’ copies, since they will vanish the minute I have to run _ResetToolbars again, which is the workaround to see your updates on toolbars.

Step 3. This is the result of such a destructive move:

Step 4. This also creates a lot more problems. If my tools (buttons) in my custom toolbars where linking to other [copies of] default toolbars, when I drag them over I will also be dragging over copies of those linked toolbars:

that eventually I have to go and purge one by one, very carefully, so I do not create more destructive damage.

I walk you through this messy process in this video:

In this video as I documented all these problems, I realized that I encountered a new ever crazier reliability problem: Rhino is somehow cashing older versions of my copied toolbars!

To see for yourself what I just showed here in video 02:

Want to see the bait and switch? Go pack to video 01 and look at 1min 25sec of where I first load these toolbars and pay attention to the shading icons on ‘Standard’, and the group/cap/extract surface icons on ‘Main’. Then in 02min 47sec you will see some of those icons are different. I also captured it here:

Also let me remind you that every time I have to make a change to my G_Main or my G_Standard I cannot do it to the ones that I’m actually seeing on my screen and using, because those are disposable copies! Instead I have to do the following:

  1. I have to go back to ‘show toolbar’ and show the ‘archival version’ in my custom workspace
  2. Make the changes there
  3. Go back to default and delete my copies of G_Main and G_Standard
  4. Drag over again my G_Main and G_Standard to the Defaulr.RUI groups.
  5. Go back to Tools>Toolbar Layout>Default and hunt for all the ‘toolbar 00’ and ‘toolbars 01’ that I had been re-copying over as linked toolbars.


This is a complete mess. This is not a good way to manage the complexity of all the problems you have built and all the workarounds of each of those problems you have also come up with.

I see the following problems that devolve into more problems:

Problem 1: Rhino updates cannot deliver us reliably new toolbars/tools in Default.RUI without running the super destructive _ResetToolbars (which BTW it closes all other working/open toolbar files, which makes no sense to me).

Problem 2: you do not let a toolbar group contain referenced (instead of dumb copies) of toolbars from other custom.RUI files.

Problem 3: if a custom toolbar has linked toolbars that are exact replicas in content and naming of toolbars existing in Default.RUI, you don’t even parse them and compare them, so simply add copies with suffixes 00, 01, 02…

Problem 4: The new one I’ve discovered recording this: You cannot even reliably copy a toolbar from one .RUI file to another!

This is all very sloppy work, that has been patched over and over in Windows for the last 20 years, don’t even get me started about the spacing and snapping behavior of them, or the icon management approach. I think for now at least you should try to make living with a “Default +” workspace a little bit easier for us, especially considering this is the most likely scenario of usage for any team lead, trainer, or educator. These are the people that help you grow your business more than anyone else, so please give it the attention it deserves.




Well spoken!
If there’s something about Rhino that feels outdated, broken or not ‘21st century,’ it’s the toolbars and panels mechanism.
There should be a good UI layout saving/loading feature.
Cinema4D, for example, has got that right.


The most important feature that is missing is “one click”(metaphorically speaking) export/import/backup of all personalized Rhino modification/configuration.
This should be (as much as reasonably possible) work between different versions of Rhino.

For instance: Want to try the new WIP? Download, install, load up your configuration file from your current Rhino and it will be set up as close as possible to your usual Rhino installation.


Norbert, Eugen,

You are talking about substantial improvements that I suppose involve major software architecture overhauling in this area.

I do agree that’s necessary at some point, but I want to make sure that your comments do not distract from the very specific, defined and well bound 4 smaller fixes I detailed here, and that I think McNeel should resolve ASAP.

We have been asking for major projects, like the complete rebuilding that you are both hinting at, and there are many areas of Rhino that could benefit from that. I’m not sure this is a most pressing one.

I rather see much more important things like Layout, Snapshots, BoxEdit (with CP/verts and subobject support), Blocks, undestructive import<>export of MCAD assemblies, responsive material editor, multi-render material support, live-link to Blender, Catmull-Clark SubD, better mesh Booleans, better Nurbs fillets/Booleans, direct editing in Nurbs that actually works, Gumbal with memory and more controls, I can keep going… fixed more holistically way sooner that custom workspaces.

For now I just want these 4 horrible bugs in toolbars fixed.


my custom toolbar file is 15mb filled with unneeded duplicates, i tried to clean up the duplicates but it broke all my toolbars so i gave up and just let it get bloated.

Hi Mr. @John_Brock, I’d like to cash my feature/fix/bug request cloud credit here today.

Thank you.


1 Like

Some thoughts:

  • I have occasional problems where I open a new file and my preferred layout has inexplicably been altered. Minor annoyance, but it shouldn’t happen.
  • One thing I REALLY REALLY REALLY want is for it to be possible to lock docked toolbars individually. I work with layers and properties on top of each other on the right, and would like to be able to lock that but to have docked plugin windows be alterable.
  • I don’t use docked custom toolbars for rhino native tools because I find the MMB toolbar much faster. But the space is limited. I would love it if we could use ctrl-MMB, shift-MMB, ctrl-alt-MMB, etc to bring up other toolbars. less mouse moving is better.
    -Is there a way to use hotkeys to toggle between fixed states of the grasshopper and Rhino window? If not there should be.

Broadly: I find it too easy to fumble and mess up my viewport, and I find it fiddly to fix it after that happens, so some of Gustavo’s broad criticisms ring true.

This is super important. Also important for people who work on different machines often. When I take classes, I always end up bringing my own laptop because universities have everything set up as default and changing settings and changing them back is too many steps.

We ought to be able to just call a command that references a single file for both options and toolbars, and there should an option within the command to revert after closing rhino.


Sorry, I didn’t want to detract from your specific requests.
Cheers, Norbert

hi RMA team,

One more problem about this:

Problem 1B: When we do have to run _ResetToolbars, the other toolbar files from plugins (besides the .Default.RUI) do come back loaded, like shown here:

but my custom toolbars file does not:

1 Like

It’s been years now Rhino UI is considered as a minor problem.

The fact is, it is annoying every day.

I’m even stressed to move Rhino from one screen to another cause I know it will mess with my layout.

It is time for a reliable workspace.


Hi McNeel team,

Besides the 4 problems I listed above, I want to report some more problems with toolbars, and I’m not sure if I’m doing something wrong but I think what I show in this video should not happen. I should not have to jiggle around my toolbars every singe time I start Rhino. Also see how my icons disappear right in front of me as I mouseover. This is crazy stuff.

Video here:

The most important of these problems in the video also documented as a screenshot here:

So please add these to my list:

Problem 5: My Icons seem to be disappearing/appearing on mouse over after I moved/copied a ‘separator’

Problem 6: Tooltip of edit button functionality when I Shift-click or Ctrl-click a button do not show the words Move/Copy.

Problem 7: Selection filter does not show all its content after Rhino closes and reopens in a toolbar window of the same exact size.




Problem 7: Happens every single time I open a new Rhino Instance.

1 Like

Love Rhino but not the UI. Needs a graphics upgrade. Looks juvenile and made me reluctant to learn the software, at first

First let’s fix the UI from a functional perspective (see everything above).
Then we can talk about the look.


I don’t understand what is so hard about getting toolbar positions right in their code. There is tons of software that uses custom toolbar positions and in not a single one of them I have experienced toolbars jumping around, disappearing, etc. yet here we are at major version 7 and things are still as broken as ever.

McNeel do yourself a favour and get a UX person or at least a PM who has heard of usability before…

I agree. The look isn’t great, but also nothing unusual for Windows software. But basic usability, ie. it works at least as expected, should be solvable and something that just HAS to be there for any serious software. Sure there is still tons of super specialised functionality in Rhino that could be added or improved. I think that is the reason all this is still there and people still use Rhino. It just has some killer functionality that you don’t really get elsewhere. But in terms of the look and feel and UX of Rhino, its a bit of train-wreck compared to other professional software (Grasshopper being the exception here - its truly excellent in UI and UX).

Yeah, I don’t have a clue about coding, but I always wondered about thais too.
What makes Rhino different from all the other programs that seem to manage this without problems?

From experience of working with product teams and developers I would say the difference is culture. Developers, researchers, scientists, etc. usually are not concerned with user experience and design and thats okay. So unless you have at least some PM, but ideally at the C-level someone who is advocating for UX and good design it is not going to happen.

That advocating usually starts when you get bought by a bigger company and they are looking for ways to make your product more appealing. I know, because I work in a team where we usually do just that. We get called in as UX specialists and look at ways to improve a product from a user (and business) perspective. In most cases you are then confronted with products that have tons of great features and so much development effort put into them, but very little put into design and usability.

So I think ultimately its the priorities of the people in charge that dictate wether a product has its focus on functionality (90% of cases) or good user experience (9% of cases) or both (1% of cases).

Long story short if you want to see Rhino be on par with Cinema4D, Blender, etc. in terms of UI it will only happen if there is a fundamental shift in the culture at McNeel. I don’t see that happening any time soon imho.

My biggest hope is for Rhino.inside and to actually use rhino and grasshopper in another 3D Tool like Blender.

I believe you are exactly right. I have shared this opinion for as long as Rhino has been around. The only part I disagree with for a company supplying a commercial product is: