Tested just for you - WIP toolbar editing 😬

Warning - long post…

Relative to this other current thread, I decided to test a few things on my own. Starting out with a completely standard Rhino I thought I would try going through the process of creating a custom workspace. I only got as far as making one new toolbar with a couple of buttons before giving up. If you have the courage, read on…

Start of test

So I started by making a new desktop shortcut with a new scheme – Recon1 (no, not Defcon1, although maybe I should have named it that). I am very glad to see that schemes – one of the greatest additions to Rhino IMO, have not been affected by the UI changes. Double clicking on the shortcut I created for the new scheme brings up a bog-standard unmodified version of the Rhino workspace. It looks like this:

I then went to Options>Appearance>Toolbars and hit the little gearwheel icon and chose “Create new file and link”

– browsed to the usual spot where .rui files are stored
and gave it the name Recon1 and OK.

Nothing in the Rhino interface changed when I did that – all the tools are still there. What I don’t know is - what did I just do? Did I copy all the default tools to the new rui? Or did I just make a new blank .rui?

In the UI folder a new Recon1.rui has been created, good, bbbut… it’s only 1Kb. So I suspect it’s completely blank. If it had some tools it would have a significant size, V7’s Default.rui is almost 9Mb.

OK, back to Options>Appearance>Toolbars. I want to see what toolbars I have. Where is the list? Nowhere to be seen and no button to open something like a “workspace editor”… OK, close out of Options and go to Tools>Toolbar Layout. Aha, there they are. Why isn’t there an access button from Options>Appearance>Toolbars?

I see in the dropdown there are now both “Libraries” – default and Recon1. Default has all the usual toolbars, and Recon1 has… none. It’s blank. Suspicion above confirmed. Funny thing, in default, even though the top and left sidebars are showing, NONE of the toolbars in Toolbar Layout are actually checked in the list…

And, interestingly enough, the + button to add a new toolbar (inherited directly from Mac, this is not a Windows thing) is active in both Default as well as in Recon1. So it is possible to add a toolbar to default. I assume this modification will be passed on to all schemes using default – will try that later.

Lets go back to Recon1. I’m going to add a new toolbar – I call it MyFirstToolbar. Then I get to this window:

It’s a little baffling at first, as everything is blank. Then I realize that I am in Recon1, but there are no actual tools in there. I would have expected the right panel to show me all the possible tools available, but that’s not it. I have to choose the library default where all the tools are in order to be able to transfer them to my new toolbar which presumably is in the Recon1 .rui.

Let’s be reasonable, I’m just going to add two tools to the toolbar, Move (which is actually linked to the Transform toolbar) and Copy. Oops, after I added Copy, and scrolled to look at something else in the command list, Rhino WIP froze, then just winked out. No crash report but I did get a dotnet crash file on my desktop. Sooooo… let’s start all over. In Options>Appearance>Toolbars, my Recon1 file is no longer linked. It still exists though. So I bring it back and hit OK, then I go back to Tools>Toolbar Layout and try to add a new toolbar and tools.

OK, successfully added Move and Copy without crashing, hit next to get the next screen.

And just hit Finish to hopefully get my toolbar. Miracle of miracles, I actually get the toolbar. Not so miraculous, you can’t make it a single row, what you see below is as small as it gets vertically.


Of course, the Move button is no longer linked to the Transform toolbar. OK, let’s re-link it. Transform doesn’t exist in Recon1, but I can link it to default.Transform. So now, I have a button in Recon1.rui that links to a toolbar in default. Hard to wrap my head around that.

OK, now for the real fun part, let’s try to modify the Copy button. In V7, I have it set to copy without history (LMB) and the same no history for Copy InPlace the RMB but it also selects the copy.

So now we get to try to edit a button. As has been mentioned in other threads, the commands in buttons can no longer be edited directly. A major cluster****. So I hit “Select or create new Macro”

– then “New” and I finally get to create my macro (which I just copied over from V7). I have THREE windows open now.

I can hit OK twice (but not three times) to get back to the button editor and then repeat the procedure for the RMB. Good, so then I hit OK for all that and finally close out of the button editor and….WTF??? The icon image disappears and is replaced with a gray circle. :rage:


OK, I open the button editor again and click on the image – thinking that I MIGHT be able to get the image back from the Copy button. Try that and guess what – it replaces my new macro with the old one for Copy. Aieee… Fortunately I can cancel out of that.

So now I realize that when I create a new macro I also have to go get the image that it should be associated with. That’s yet another two windows (four actually), first click on the gray image box which brings up the pixel editor, then the gear icon, File, Import standard Rhino image…

Then scroll through the images to try and find Copy – and guess what??? It’s not there!!! Plus at any given moment the scroll window disappears and the whole Rhino window glitches. Toolbars gone, etc. Looks like this:

Minimizing/maximizing the Rhino window brings back some of it… slowly. This is really not ready for prime time! Try again, this time instead of scrolling in the image choice box, I try the search function, and lo and behold, I find the Copy icon because it’s labeled “Main 1 Transform Copy” or something like that - and I was looking for it in the “C”s.

So, finally that works. Phew. But that certainly isn’t going to work for hundreds of buttons – I’ll be at it until V9 comes out. Yahhhhhh.

One last thing before I stop here. Using Ctrl+LMB/Drag, I copy the Rectangle button from Default to my new toolbar. I unlink it from the rectangle toolbar. Now, I want to paste a Python script in there that I have that selects rectangles, and it’s 40+ lines long.

I go through the “Select or create new macro” rigamarole, set the Recon1 library, press New, re-browse to find the rectangle image (because the existing one gets thrown out when you hit New) and then – try to past the script into the…ONE LINE place for pasting a macro – which cannot be expanded. It looks like nothing has happened. The line remains blank. But something has been pasted in there, it’s just invisible, you can hit backspace and see lots of blank spaces in there as the cursor moves. I give up and hit OK and it shows me this:


Tried various things, no way to get a script into the button (except maybe a one-line link to an external script). OK, I’m going to give up for now – this is just too, too broken. It’s free-fall down the rabbit hole - and no bottom in sight.

OK, I tried once again and this time I was able to get a script pasted in - I was trying to put it in the wrong place. However, it’s a real nightmare. If you want two different scripts in LMB/RMB you can try this - edit the LMB box with all the associated craziness and get the script pasted in there. Then go back and edit the RMB box and paste a different script in there. OK out of that and you find… the second script has replaced the first in both boxes - you now have the same script twice.

The only way to have two different scripts LMB/RMB is to DUPLICATE the macro you made with the first script and then edit the duplicate and put the second script. This is beyond crazy. This linking of stuff has gone so far over the edge it’s now just a huge hot mess.

PLEASE UNLINK EVERYTHING !!! You have completely destroyed a system that was simple and elegant and allowed even relatively inexperienced users to customize their workspace - one of the best features of Rhino since the beginning.



Thanks Mitch for trying this out and writing it down.

1 Like

Hands down for the dedication and effort spent to test and describe everything wrong with the customization of Rhino 8 WIP.
I agree that Rhino 7’s customizability was spot on. It’s pity that Rhino 8 WIP is way worse in this regard.


Thanks for digging into this, Mitch. I now have at least a rudimentary understanding of why I can’t seem to simply customize my Popup toolbar. Tried for an hour before I gave up.



1 Like


The other important factor for me at least, is that whatever UI that I eventually come up with has to be portable. I’ve got to be able to copy it into many more computers.

1 Like

Yes, the whole toolbar system is completely messy. Not just in V8 but even before. Plugins create their toolbars that will just appear when starting Rhino. The amount of times I had to manually close all 10! of V-Rays toolbars because they decided to show up again. Other toolbars will disappear even though I have added them many times.

Why does this have to be so complicated, while being so static? If I spend all this time customizing Rhino I want to be able to at least use it on several machines easily or restore a previous setup that was working.


I had a similar idea to you, Mitch, and created my own version of the default menu and swapped it in, replacing the McNeel one, added a button, created a dropdown toolbar to display sub buttons when the button is clicked and, while it was hard to work out how to do all that, and the random distribution of tools didn’t help, and there were numerous false starts, I felt I was getting somewhere, even if half an hour seemed like a long time to get to one new button (heaven knows how long if I’d got into the icon editor!).

But then I went to look at what McNeel put in a typical macro to display such a dropdown toolbar and… …Rhino froze. At that point I shrugged philosophically (a.k.a. swore) and walked away. It’s a WIP and it just isn’t ready to explore this part.

I look forward to trying again after McNeel have created (or received) a collection of scenarios that illustrate real-world use cases and written a cohesive set of tools that facilitate those scenarios.

Incidentally, I would hope that, if any of the disparate maze of tools I wandered through were legacy items and not intended for use in R8, they can be disabled or removed to avoid confusing the landscape.


Thanks for taking the time to write this. It deserves an equally long response, so here goes.

But first, a bit about where we are with this project. There’s a lot of new code here, and the UI for it is not yet done. As you’ve discovered, it’s gross.

First, our intentions

There are a few new features coming to Rhino 8 that are designed to fix a few very painful long-standing problems in Rhino.

1. Cross Platform: This new toolbar and window management system works on both Windows and Mac. On Mac, you didn’t have much if any customization available in Rhino 7 and older.

2. Toolbars Stay Put: This change makes it so that all the dockable stuff in Rhino can live in any of the containers. It also is stored in a way that when you close Rhino and re-open it, you get what you had. For some people, Rhino 5, 6, and 7, never really worked this way.

3. Delivering Updates, Not Trashing Customization: Another thing we’re trying to fix is the ability to add new tools to Rhino without trashing everyone’s custom RUI files. This is actually a big deal. Let’s say we find a bug in the Circle button: we shipped with a macro -_Coircle and it just didn’t work. And you built a new custom layout of your own based on our default RUI. In the past, if you wanted the fix, you had to know to look for it and update your RUI. Now, because your changes to the RUI are stored locally as a set of changes (rather than a whole RUI file), we can modify -_Coircle to be -_Circle and both the default and all your changes will be updated.

4. Combining Tools: It used to be that if you had the VRay plugin loaded and you wanted your own new toolbar that had some Rhino tools and some VRay tools, you’d get a bunch of copies of those tools in your new toolbar. Now, Rhino will save links back to the original RUI files (for much the same reason as above) so that the original authors can update and change their RUIs.

And finally, if you’re one of the very rare people who design whole new layouts for Rhino (and, I know, you are) there are tools for un-linking everything and embedding it in the RUI.

Second, Our priorities

I got my hands on this set of new tools about six months ago. At that point, just opening Rhino felt foreign. All the styling was confused, things didn’t line up, there was a waste of pixel space, etc. Dark mode didn’t work (and still kinda doesn’t).

There were a bunch of things that didn’t work when you simply opened Rhino and tried to use it. We are very nearly done cleaning all of that up. And it’s our top priority - because using Rhino is way more important than customizing it for most of our users. I’m not saying customization isn’t important - but I think it’s not controversial to say that using Rhino is more important than customization.

I intentionally pulled people’s focus away from toolbar button creation, workspace creation, and layout editing in favor of straight-up default user experience.

And now, we’re turning toward some of those more subtle things like what you’ve described. And yes, it’s far from being done.

I was just talking to John about this, and wondered what on earth “and link” means? Why isn’t this just “New…”? Logged as RH-73818

Maybe there should be. I’m not sold on that idea yet… doing so means you have a modal options dialog with another Toolbars dialog on top, and then all the editing you do happens on top of those two windows, pretty well obscuring what you’re working on? Or am I missing something here?

That looks like a bug. I’m not sure those checkboxes actually are hooked to anything. Since toolbars can belong to multiple containers now, a checkbox is kinda nonsensical. It looks like you can cause toolbars to appear with those checkboxes, but they don’t seem to have a visibility correspondence: RH-73819

The intention here, which clearly didn’t work very well, was to help guide you through the process of creating a toolbar and adding buttons to it. If you were doing this in the context of the default RUI, I think it’d make more sense. But since you started with nothing (an empty RUI) it’s less sensible.

Logged as RH-73820

Yep, that’s by design. So that we can update that linked toolbar and you don’t have to care. Glad you love it :wink:

This is currently in the category of internal conflict. Some of us agree with you. Some of us don’t. I’m not sure where we’ll land ultimately - but even if we keep the “buttons reference macros” concept, we’ll streamline the UI so that it’s not so many clicks to do things.

All the rest, I just agree with, and we have bugs logged for them.

Thanks: RH-73821

I refer you to Rhino 7. Everything is unlinked there. But seriously, we’re going to continue to fix bugs and make it better - it might be a few months yet, however. :rhinoceros:


Hey Brian, Thanks for explaining all this. I think the priorities you listed on your post are the right ones. I read about the issue that Mitch and Dan and others have been having with linked toolbars, and I was feeling really guilty, because I know I’ve lobbied for linked toolbars pretty hard. I still believe they are necessary.

I know is really hard work to get this right. Actually, I probably have no idea how insanely hard this must really be. But I really look forward to a future when I can maintain a set of custom tools that people in my team can use, linked to their source file, and that I can update them on my end and they see those updates (our .RUI files live in synched Dropbox folders). And none of that conflicts with you guys at McNeel also updating your own toolbars/defaults and we all also get to see those updates. And noting break anything.

Also having everything look the same on every machine that I use, every time I launch Rhino is really needed. Currently, every time I start Rhino 7 my first thing to do is rea-ranging toolbars. Every, single, time I launch Rhino. So thanks for fixing all that!

Thanks again, and keep it up!


I can understand your thinking for copy-by-ref between RUIs, but you’ve got a whole mess of people thinking they are tweaking their copy of a button while overwriting the default version. That’s not how it’s ever been, and there is nothing to alert the user that they are editing the default macro in a custom RUI.

You have to make default macros read-only. If someone tries to edit it, you silently spawn a new instance of the macro in the RUI that owns the parent toolbar. No need for a duplicate button. You edit, and you get something new. That way Rhino updates the read-only defaults and never touches someone’s customization, no matter what RUI they live in.

This conflict does not exist amongst users who’ve tried to make their toolbars in v8.

1 Like

Hi Brian,

Since we’re doing point-counterpoint here…

Of course, agreed.

Yes, a very good improvement. But for me containers and how they are arranged/docked etc. are separate from the contents of those containers. The container system is fine. What it contains is what I am questioning.

I’ve never really been affected by this, but OK, not a problem.

Never really experienced this either but hey, maybe I’m the exception.

Please elaborate on how to unlink stuff… I would like to test.

Just the expectation that if one goes into Options looking for toolbar options, one should somehow have access to the editing system…

Well, not exactly - you might find some of my and other’s previous posts concerning concerning copying buttons and having macros, tooltips etc. come with them - in V7.

I’m glad that’s not a serious response. Well, maybe it is finally time for me to quit mucking about with this stuff and really finally retire along with Rhino 7.

I simply want to state that if you end up tailoring the system to a collection of high-end users at the detriment of lots of the lower-end ones, I will be very sad.

If you have a way to export the default toolset so that it is completely unlinked from the totally interconnected dialog box jungle world it currently lives in, and in those unlinked tools I can simply open a button editor, type or paste in macros, scripts and the like, choose from a library of svg images and OK to finish, I will be fine with that. (hmm, sounds about like V4 doesn’t it…).

if I can shift-click a button I just copied, type a macro, and click ok, then I don’t care how the rest of it works

besides doing that, I have not sunk a second of time into customizing rhino toolbars since I did it in v2 or v3, only for the next version to come along and not support the workspace I had spent so much time making, and become dependent upon; that sucked, but it was also good, because it was what taught me to never customize software

sidenote on the point about needing to link so you can fix things without disturbing user customizations – you know what string was wrong, and what string is right, so you don’t need to replace the toolbar, just fix the known bad button macro

It’s in the Tools > Options > Appearance > Toolbar Layout > Gear > Save Changes to Linked File.

(I have no idea why it’s called this, makes no sense to me)

That will be a sad day, indeed.

I know, I’m with you. I don’t want you to need to be a database wizard to manage these things, either. I hope we can make it better in the coming months.

Sure, and also the bitmaps. Oh and add a new button. Oh, and delete one. If only it were easy! Maybe we could just overwrite everyone’s customizations :face_vomiting:

Do you do 3D design and 3D modeling for a living?

I do. And I can tell you that without custom tools, workflows, scripts and plugging I’d be a lot slower at what I do. And my days would be a lot more repetitive and boring AF.

Bad for me. Bad for my customers.

I see Rhino mostly as a 3D operating system that allows people like me grow businesses with a lot of custom tools and workflows. I really hope Rhino continues to nurture and support this type of work going forward, because no one else does. The world does not need yet another defaultware 3D package. That’s a crowded market.



That’s actually not how it works, either. Unfortunately this whole system is rather complicated, and may almost be impossible to get a sane mental model of.

When you edit a button, you are actually editing a small “delta file” that records the differences between our defaults and your changes. When you start Rhino, that “delta file” is read and applied to the defaults. So the core, unmodified macro is still there for you.

If only we could have all of you type on the code at the same time, all our disagreements would be solved.

no (but I have to use about a billion tools to do development), and I’m not saying what works for me has to work for anyone else, let alone someone like you, who is creating custom workflows for entire teams

It is how it works. After spending a day filling a delta file with stuff that should have gone into a custom toolbar, I finally understand it. And I’m ready to rage quit.

There is no way V8 can launch if editing a copy of a button in a custom RUI replaces the stock button in the default RUI.

Just remove the duplicate button. If someone edits the macro, silently duplicate that macro in the RUI hosting the toolbar. That way, you create a new command on that button without overwriting the existing macro on every other button.

If it’s an edited macro, Rhino shouldn’t update it. And if it’s unedited, it remains a by-ref you can update at will.


This is a really fundamental flaw in anything designed for users. It’s also a serious obstacle to practical intuitively usable design when it’s true for developers.

BTW: I personally think that unless Mitch is already getting incredibly rich as a Rhino reseller you really need to send him a generous check for the billable hours he spent on this!

1 Like