Suggestions for converting a V7 or previous custom workspace to V8

I’m posting this as a separate item from my previous comments on the UI, because it involves perhaps some more specific procedures/recommendations concerning toolbar layout conversion from earlier versions.

I will now need to start re-creating my custom workspace from V7 and earlier with a lot of custom buttons - but all of them have bitmapped icons and I would like to take advantage of the possibilities offered by the new vector based button images. So I guess I will start from scratch again…

Previously, I used a complete copy of the default workspace as a base to which I added/modified buttons, custom toolbars and the like - so the normal default.rui was never open. Now, it seems like that is no longer the optimal way to do this. Because in V8, the default stuff is still there even if you close all the toolbars. As a matter of fact, default.rui no longer exists as of the latest WIP. Nor any other .rui as fas as I can see, my custom .rui is no longer modified when I close the WIP.

So, I am trying to figure out how this is designed to work now. It seems more like that one simply should add any custom stuff one wants as a separate container and leave the default as-is… In any case there’s no longer a separate .rui file to copy or save elsewhere. This however brings with it some interesting issues - for me at least.

First and foremost, I work with schemes to have Rhino start in the three different languages in which I work/support. I have one scheme each for English, French and German which all open with the bog-standard default workspace - so I can see what the customer sees when they call for support, test for bugs, do demo videos, etc. Then I have a scheme with my personal custom workspace for my own stuff.

The three V7 default schemes all call up the same default.rui located in the usual spot:


This is not a problem currently because I never modify that file.

Now, for V8, the default.rui no longer exists. I leave the default toolbars open I can certainly add my own custom ones separately, no problem there. However, in V7 and earlier, I have also modified some of the original base toolbars, adding items, sometimes flyouts and changing images. The problem as I understand it is that any change I make here will also modify the workspace for all of the other schemes that use the default.

I’m wondering how to work around this… I need to know what changes I make in one scheme will be transferred over to the others so I can avoid destroying the default setup. Also what updating Rhino will do if one has modified any default elements.

Edit -
It seems that modifications do not carry over to other schemes, so that’s good. I tried copying a couple of buttons in one scheme and the copies did not get applied to another scheme. I also tried changing the button image in one scheme and that did not carry over to another scheme either. So far so good.

What I did notice is that if one changes a button image, one has to close Rhino and re-open it to have the changes take effect. Also if one has several instances open (in the same scheme) the last to close overwrites the change - like currently.

1 Like

Hi Mitch -

I also use several schemes for all Rhino versions.
In Rhino 8, any workspace that you save will automatically be accessible from all schemes.
I can’t completely follow what you are doing though - it sounds like you are modifying the Rhinoceros Default workspace differently in the different schemes but then not saving those modifications as custom workspaces?

Yes. In this case I do not want the Rhinoceros Default workspace to be modified. As there isn’t a default.rui anymore, where is this info stored?

My issue is that if I have my custom scheme - which has a “linked .rui file” that contains some of my personalisations, but I also have Rhinoceros Default open (don’t see any way to close it actually) and I modify a “standard” toolbar button by changing the macro or the image - that this will propagate over to the other instances where I want to have a completely unmodified default workspace.


Hi Mitch -
I always run into problems understanding what is being said when words are used that have several meanings. Sorry for being slow…

“Modify”, in my mind and in this context, can either mean dragging UI elements around and not doing anything else, or saving a new version of the workspace. The latter cannot be done for the “Rhinoceros Default” workspace but there is nothing preventing you from doing the former.

If you only have the “Rhinoceros Default” workspace and rearrange UI elements, exiting and then restarting Rhino will show this modified workspace. We’ll have to ask @JohnM where that information is stored, but I’m pretty sure it’s not in a file that is shared by different schemes. To test this, from a “Rhinoceros Default” workspace, I pulled out the Layers panel and exited Rhino. I started Rhino from a different scheme that was also running “Rhinoceros Default” and that did not have a floating layers panel. I then started Rhino from the first scheme and had a floating layers panel.

Restoring a custom workspace will “close” the “Rhinoceros Default” workspace.

I can’t tell if this is a concern of something that you can reproduce. My test of pulling out the layers panel seems to indicate that this is not happening.

Maybe I’m being confused by this:

I wouldn’t have expected Default to be shown if it wasn’t “open”

Some more odd stuff here -

This is what V7 looks like with same workspace:

Note also the longer names in the left panel are truncated.

I also don’t understand how to create a copy of the default and ‘save’ it under a new name…

I see, I’m not sure where that “default” comes into play. I would expect there to always be a “default” entry there (factory-default that is baked in and cannot be messed with) but it doesn’t look like that includes all toolbar icons that are in a out-of-the-box Rhino?

I don’t have multiple entries for those containers. Also, the “Toolbars” section in that dialog doesn’t have anything to do with the “Containers” section to the left.


I suppose that they might be the result of bringing in a V7 toolbar (linking the rui). What happens when you restore the “Rhinoceros Default” workspace? (but read on before you do that)

Well… v7 doesn’t have workspaces, I’m not sure what you are showing me here.

I see that, I’ll get it on the list.
RH-69854 Containers: Allow long names

I guess we should start there.
Run the Workspaces command. Since what you are looking at on screen is your modified “Rhinoceros Default”, clicking the + button will allow you to save those modifications as a custom workspace:

To restore, delete, update, or export a custom workspace, right-click and pick from the list:


Hi Wim, Mitch - out of the box can be restored with ToobarReset. The Rhino Default workspace can also be restored in the Workspaces command - this is where most of the action is, I think, when it comes to custom layouts. One thing to keep in mind is that Workspaces knows about containers but not what is in them… so you may indeed need to make custom containers to show and hide with workspaces.
Different schemes should stay separate - each will have its own placement file that knows what is showing and where.


V7 has .rui’s to manage the toolbars. It’s part of your “workspace” even if it isn’t called that. What you see is Options>Toolbars in V7.

And yet another command line dialog that isn’t accessible via Options…

Hi Mitch - this part is still in churn - but it will be different - basically you’ll, in effect, export differences from the default. I am actually chatting with the developer about how exactly that will work.

OK, I figured it would be something like that… As per above my main worry is in my custom workspace being able to modify, say, an icon image of a button that normally resides in the default config but not have that get pushed into the other schemes that use only the default.

For example my bad bitmapped modified selection icons

Hi Mitch, I think you’ll need to do something special to have those changes shared across schemes.


So let me try to define the various terms now being used and their definitions/uses. I will correct and add to this as we go along.

Complete collections of Rhino interface settings including arrangements of toolbar buttons, panels, and some other UI elements such as the command line and Osnaps etc.
Does this include: Appearance settings? Display modes? Aliases/Keyboard shortcuts? Answer: No.

Part of a workspace that can contain/group tool buttons, other containers, panels and some other UI elements such as the command line and Osnaps etc.

Groups (bars) of connected tool buttons with a name for the set

A command, command sequence or script that actually gets executed when a “button” containing it or an alias referencing it is called. When used on a tool button, a macro is associated with a vector-based image (by default in V8+) or a bitmap image (imported or from a previous version) for that button.

Macro Libraries
A collection of macros that can be edited and saved under a name.


You are right, I was surprised when I read the new Ul, imagine that you are updating Windows XP, it is outdated.

This is just my understanding of it…

Technically, the command line, the Osnap, and the Filter dialogs are special UI elements.
Appearance settings, display modes, aliases, keyboard shortcuts, and custom toolbar icons are not included.

Custom workspaces, when saved, are written as xml files in %appdata%\McNeel\Rhinoceros\8.0\settings\workspaces.

Workspaces can be exported to be shared with others.

Containers do not contain other containers. They contain panels, toolbars, the command line, the Osnap, and the Filter dialogs.

As a macro can get called by an alias or keyboard shortcut, I wouldn’t say that it is associated with a vector-based image.

“Macro Libraries” - the Libraries command will still open the library with rendering materials.


Hi Wim
I’m not able to insert the filter dialog into a container… [the Osanp yes] is that just a Mac unfinished thing?

Hi Akash - the selectionFilter is somewhat special and problematic in the current scheme of things - because it it not active when not showing - by design - it makes it harder to treat as just another UI thing that might end up behind some other panel but not actually be closed.


Well, I said that because apparently the only to find/edit the image associated with a tool button ‘macro’ is to go through the macro editor.

Instead of starting from scratch, is there some way to import all my custom buttons from Rhino 7? It seems like it would be WAY easier to import all the custom buttons and modified toolbars then just go change the icons for the new vector based images when I get around to it…at least the functionality of the buttons would be imported and not need to be re-created… which would be a LOT of work… I would have to open Rhino 7 and Rhino 8 at the same time and copy and paste between them for every single button… it would be very tedious.

It seems like one should be able to open the Rhino 7 .rui file… Rhino 8 would know how to apply it, and then save it in whatever the new format is. Is this possible somehow?

Yes, you can do exactly that. I am currently using the imported V7 with bitmaps until I get around to changing them. I am also waiting for the interface stuff to stabilize a bit more before I start doing any serious mods, as it’s still pretty wonky (IMO).

1 Like

How is this accomplished? I don’t see how to import the V7 .rui file