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,

12

I had tons of issues and crashes after transferring my Rhino 7 options into the latest Rhino 9 WIP. I gave up entirely and started a manual customization of the WIP from scratch. Hopefully the bugs will be fixed in the future and the transfer of settings from Rhino 7 will be smoother.

13

Hello Callum & other devs!

I am happy that you have heard the community again

As I read this topic, questions so far have been mostly focused on migrating the settings between the versions.

I would like to bring up a few thoughts that represent this issue from admin-user point of view.

In our company we have many users and ideally we want to control their installations to certain extent.

We would like to ensure that all installations are on same SR, we would like them to have same set of aliases, maybe keyboard shortcuts, etc. and all that with minimal amount of administration.

Our problem has two chapters - 1) installations to new computers and 2) maintenance of the existing installations. Each of those has even more details to it. I try to describe what I can.

1) NEW INSTALLATIONS

We had to spend some time aligning with our IT so that they always install Rhino with automatic updates off. (Sidetrack: I would still swear that my Rhino version had an update pushed a couple of times even with that setting. Do you from time to time force update when you uncover serious bug in Rhino? Now back to the topic…)

So we have all Rhino’s installed with updates off and in our internal documentation we have “latest verified SR” where we are confident enough to say that all the tools (mainly GH scripts) are working as intended. That is the version that out IT will install. After installing Rhino itself, IT has to do some more settings to get something we call “valid installation”: they have to install all GH plugins we use, again in verified versions (we can’t automatically accept the latest), in relation to that they must turn off automatic plugin updates in Package Manager and install our custom common Rhino aliases. I can imagine there might be more custom settings in the future (eg. local .yak source, display mode settings, render materials, etc.)

The key conclusion I made is this: we would ideally need an ability to turn existing “template” installation into an “installation image”, that could be deployed onto new computer/user without having to do all of this step-by-step. Or, alternatively, setup a functionality from 2) that follows, which might also do the trick after vanilla Rhino is installed.

2) MAINTAINING EXISTING INSTALLATIONS

Once user has Rhino installed and set up as above, we are struggling to keep everyone updated once something in the initial setup changes. For example - when aliases change, we have made script that updates them using source files in a server folder, that user can run. With GH plugins, it is more complicated. We tried to use an .exe that would kill Rhino, move predefined set of plugins from server folder to user’s computer and thereby install the versions we determine, but we had issues with permissions and some more problems.

All the sub-optimal solutions above have one thing in common - we have to prompt user to do something, or make IT assistant connect to each computer and do it (no-go). In ideal case, we would need to connect each installation to some kind of setting file (yes, that could be the .rhs) that would be fetched everytime Rhino starts, if the timestamp of the .rhs file changes. That way we would only be able to maintain one settings “image” and distribution would be automatic.

It could also partially replace the “installation image” described in 1), as long as we are able to install new Rhino with some kind of “settings path”. Worst case the definition of this “settings path” would be the only manual step done by IT and then the rest would be fetched from then on. In ideal case we would like to predefine it somehow, so that Rhino installations can be fully automated via Company Portal or whatever they use. I can get more info if needed.

So as I see it, the way of lowest resistance would be to allow Rhino installation with optional “settings path” similar to Zoo server path, and then create a mechanism that can effectively fetch updated settings (no matter what exactly they contain).

Then there’s whole another discussion, and that is what all should be contained in settings image and how to solve conflicts with local user settings.

Admin wants to have complete control over certain settings and user wants to be able to set up anything he needs to work effectively. As half-user/half-admin I can understand both views.

I would appreciate some way to “lock” certain settings from the settings image while leaving the rest in control of user. For some content like Aliases or GH plugins we could (and that would be even more simple) lock anything that comes from image and leave the rest editable. That would effectively freeze our predefined aliases, but would still allow user to do his own. It would freeze versions of our essential GH plugins, but would allow user to install some more, if needed. I am sure you get the concept.

If any of the suggestions above made it to live version, that would be just perfect. I believe that we are not the only ones facing these challenges.

14

Hello @Ukrutony!

I don’t believe so. The setting should always be respected.

There is a yak.exe CLI inside the Rhino install (and also available via a url) which can install plugins to the latest or a specific version, this may work better for you, as it’ll do it whilst Rhino is running and Rhino will use the newer one when it next starts up.

Thanks for writing all of this up in such detail, it’s really interesting and mirrors some of my pre-McNeel experiences.

I think this is my takeaway from all of this and this and it is a need we’re aware of and we’re thinking how best to solve this :thinking: . A large number of Rhino’s settings (Aliases, shortcuts etc.) are in a single XML, and deploying that XML shouldn’t be too difficult.

One idea that also comes to mind. The .rhs is just a zip file with stuff in it. Someone (maybe me) could create a small, open source, cross platform tool that takes a .rhs and moves it into the correct location of a Rhino versions settings. Then you could in theory have that little tool run whenever and ensure the user has the latest settings. The latest version of this tool also handles migrating yak packages across too.

15

Hi Callum,

thanks for detailed response

There is a yak.exe CLI inside the Rhino install (and also available via a url) which can install plugins to the latest or a specific version, this may work better for you, as it’ll do it whilst Rhino is running and Rhino will use the newer one when it next starts up.

yak.exe we will investigate, thanks for pointing that out.

One idea that also comes to mind. The .rhs is just a zip file with stuff in it. Someone (maybe me) could create a small, open source, cross platform tool that takes a .rhs and moves it into the correct location of a Rhino versions settings. Then you could in theory have that little tool run whenever and ensure the user has the latest settings. The latest version of this tool also handles migrating yak packages across too.

Yes, it could be something of that kind. In short a way to point Rhino somewhere where it can pick up all the settings and packages without someone having to actively take care of that over time. Basically one-time setup step.

Do you have any intention to handle the settings conflict I described above (template vs. user setting) or that’s too difficult? We don’t want to give our users chance to break something but at the same time we don’t want to restrict them where not necessary.

16

Yes exactly, it could even be scheduled!

I’m not sure, or what I can promise in this regard. I’d have to ponder it :slight_smile: