Rhino WIP Feature: Transfer Settings [Update]

Serengeti (Rhino WIP)
,
1

Transfer settings between Rhino easily cross-platform

We’re excited to introduce an improved Options transferring experience in Rhino WIP! We hope these new changes can make backing up settings, moving computers and distributing Rhino settings to your colleagues, students and friends easier.

Which data is included?

Note : This is only for OptionsExport / OptionsMigrate

  • Window Layouts
  • Keyboard Shortcuts
  • Aliases
  • Plug-ins
  • Schemes
  • Default RUIs
  • Advanced Settings
  • Window Positions
  • Rhino Options
  • Custom RUIs!

It is also worth noting that Window Layouts get their paths replaced during transit, so they will point to their corresponding RUIs correctly, which you may have found to be an issue if doing this manually in the past.

Which versions are supported?

Win/Mac

8 → 9 is fully supported

Win only

7 → 9 is mostly supported but has some known issues with Custom Toolbars that will be resolved.

5/6 → 9 is WIP

Exporting

The OptionsExport command exports a .rhs file of all your settings. .rhs files allow for exporting and importing your entire Rhino setup.

For users who like the existing .plist/.ini system, these are included in the .rhs file which can now be chosen from OptionsImport.

Importing

OptionsImport will work as it always has with no changes. For those who’ve never used this, you can import from a settings file which merges with your existing settings. NOTE : This is platform specific, you can only import from the OS you exported from.

OptionsMigrate will let you migrate your entire Rhino setup from a previous version, a .rhs file export from another machine or even a backup created by this or Reset. The process should be easy for all users and make moving versions, machines, and operating systems very simple.

image
image1406×1042 115 KB

OptionsMigrate replaces the OptionsImporter and PreviousOptionsImporterThe commands were a bit confusing, and they didn’t fully capture what they can do.

Data safety

All of the above commands (should) create backups of everything they replace, so you should never lose any data whilst using them. Having the files bundled up as .rhs also makes backing up easier. (This is, of course, the Rhino WIP, and this release is in need of external testing!)

.rhs files

.rhs files can be dragged and dropped onto Rhino instead of using the command.
.rhs are Rhino Settings files that are a simple renamed zip file. You can rename them back to .zip and unzip them as necessary.

Please try these commands out and let us know of any issues.

2

The command OptionsExport in Rhino 8, lets me save a .ini file, not a .rhs file.
OptionsMigrate is a unknown command.

3

This is new in the WIP version, you won’t find it in v8.

4

You run OptionsMigrate from the WIP, and specify V8 - it’s the inverse of doing an OptionsExport fromV8. There is currently no way to choose which options, it migrates all your V8 (or V7) settings. This includes if you have toolbars in a custom .rui in V8.

5

I tried, and indeed the layout in 9 is now as it is in 8, but my custom toolbar is corrupted and trying to use it causes Rhino to crash.
I have the feeling that my earlier struggles with the custom UI might be a cause for these troubles. I have several .ui, .rhc,and .rhw files on different location on my PC, with possibly the same name.

Schermafbeelding 2026-05-02 161630
Schermafbeelding 2026-05-02 161630431×124 2.36 KB

6

Ok, thanks!

7

One thing to understand is that much of this mess is caused by the mixed-up (to put it politely) toolbar system instituted in Rhino 8. The decision was made to remove the default .rui file where all of the basic toolbars are stored and replace it with a hard-coded set of default toolbars plus a series of .xml files that only included any modifiications. The system was far too complex and fault-prone, but unfortunately inpossible to back out of because it was introduced late in the game of the V8 development process.

@CallumSykes is doing an incredible job trying to untangle this horrible spaghetti mess and get back to a system that is simpler, more reliable and understandable. Towards that end, we are back to .rui files including that have all the toolbar info. To this you can add one or more custom .rui’s if you wish.

The problem is that an exact migration from the V8 mess is complicated. Callum is trying to make it 100% perfect - kudos! - but my take on it is that it will still possibly require some fixing once the migration is complete - hopefully minor. You’re most likely going to want to modify stuff anyway given the number of new tools and processes in the latest version.

One thing to check is where your custom toolbar is located in V8. Most people just went ahead and started adding/modifying tools in V8 without creating an secondary external .rui, - which means any custom toolbars are still defined in the default library, and all the custom info is contained in the ‘differential’ .xml files in settings. This is a very unreliable situation unfortunately.

I would do a factory reset in the WIP (Reset) before running the migration tool. Then see if your custom toolbar(s) import correctly. If not - depending on how extensive they are - I would just make new ones directly in the WIP, copying out scripts etc. from V8 and adding images for icons. At least that way you should have reliable, working tools.

8

Thanks for your clear and honest explanation.
Luckily I have not spend a lot of time with creating toolbars for 8, and rebuilding them is no problem for me. And indeed, in 9 there are some new great features that will definitely push me towards new custom toolbars.
The reason I did bother so much is that I have plans to create new toolbars for a new project, and that I need to be sure I can use them without the need to rebuild them from scratch in let’s say the next 5(?) years.
And that I fully understand where my custom UI is stored and how to share it without problems.
Thanks for the hard work of the people of Mc.Neel, the newsgroup (I am old…) and the forum, who have given me so much since Rhino 1.1.

9

Yeah, tell me about it… :winking_face_with_tongue:

If it was me, I would create a new .rui in the WIP just for your custom tools. So you would have the default .rui and your personal .rui. running at the same time. That would also make it easier to transfer your custom tools elsewhere if necessary.

image
image670×505 9.79 KB

I migrated my stuff from V8, it was almost perfect in terms of usability, just a couple of small problems. That being said, I’m not so sure I am going to keep it that way, as there is still a number of issues that need fixing. One of them is that a bunch of my custom icons use the V8 “color scheme” and they are now randomly mixed in with the new WIP colored icons.

image
image180×495 30.6 KB

Prior to V8, I had everything in one big .rui. Basically what one did way, way, back when was to make a copy of default, rename it and start modifying. MIne of course got added to and modified with every new version, and even completely re-made a couple of times. That was how it worked back then and it was relatively straightforward.

image
image325×150 2.58 KB

The original default.rui was left untouched and I used it to have the default interface for teaching etc.

Then V8 came along in WIP and I made the mistake of modifying the default “library” (there was no longer a .rui for it) plus creating my own custom extra .rui. My left side toolbars live in the default library (with mods) and my top and bottom ones live in my custom .rui. Due to the awful way that the toolbar management was programmed, my macro libraries for both were (and still are) a complete and utter mess. I gave up trying to clean them up.

So, I am seriously considering starting 100% from scratch for V9. I am going to wait for things to stabilize a bit more though. It’s a good couple-three of days work to do that, much of it will be making new .svg’s. Going to have to see with Callum how all that stuff will now work, as it appears that the macro libraries have imported over from V8 with the migration and I don’t yet know which ones are actually used/usable.

10

Your explanation makes it a lot easier to understand the situation we are in according to the UI.
Seems wise to wait a while before starting creating a custom interface.
Thanks again,