Trying to transfer a few V7 settings from one computer to another. A number of things seem not to be working. First, an .ini file was created using OptionsExport and transferred to the new computer.
Attempts here to import some individual settings by checking boxes in OptionsImport results in the following:
Mouse: No change
Modeling Aids: No change
General: No change
and the worst:
Appearance: completely messes up my custom toolbar layout because the command prompt, docked at bottom, goes to the top, while the toolbars that were docked alongside it stay docked on the bottom.
In principle, Appearance should have nothing to do with toolbars, but I think the command prompt checkbox included in there is causing a reset of the placement - which by default is on top, and getting it to stick on the bottom has been buggy from the beginning - the only way being to actually undock it from the top and then redock it on the bottom.
On top of that, importing the Appearance section does not change the stuff itās supposed to - the interface colors.
Hard to believe this stuff is so badly messed up.
Oh, and also, the Help entries on both of the above are also pretty āunhelpfulāā¦
Well, in my humble opinion this whole system needs to be completely redone from scratch. The basics of this date back to V3 (IIRC); many things have radically changed to the point where some of the entries donāt even make sense anymore. Hereās the list for reference:
Problems
Overall:
The detail of what can be imported is confusing and no longer granular enough. Most of the options pages now have sub pages; OptionsImport mostly refers to the top-level pages, itās not clear if it imports settings from the sub pages or not. In one or two cases, there are redundancies, such as General and Never Repeat Commands - which is a subcategory of General; also the Context Menu entries which are sub-pages of Mouse.
Specifics:
Advanced display: the name makes no sense - that refers to the pre-display mode days settings. What does this cover exactly - all of the display modes? IMO, this should be removed from OptionsImport; importing display modes should be treated separately (see later).
Display: what does this cover? How is this related to the above/display modes?
View: again, now display modes are under the View pageā¦ covered? Not covered?
File: the option page is named Files. It also has a sub-page āsearch pathsā. Included? Search paths is also a separate item further down. Importing paths (including autosave and template files) is always risky as paths may differ from one installation to another; maybe this needs to be handled differently.
Appearance: includes languages? Colors?
All of the above needs to be completely detailed out in the Help entries as well.
Final note concerning display mode export/import:
Within the same version, normally not a problem, except perhaps if a display mode includes a custom material that references a texture file that doesnāt exist on the importing machineā¦
We have had problems importing display modes from previous versions because certain types of settings had changed. IMO, we need a separate ādisplay mode converterā module that can convert display modes to be compatible between versions - ostensibly to allow custom display modes to be imported from previous versions and work correctly.
Youāre right; itās a pretty old system. Iām not sure why we are even making ini files anymore as the settings system is all xml based now and you could probably achieve what you want by copying your settings.xml file to a different computer.
I thought about that too, I didnāt do it because I was not sure if all the settings should transfer safely between two different machines/setups and simply copying the whole file over doesnāt allow one to choose which options one wants to transfer.
If the old .ini system is obsolete as it seems, it should be completely removed and a new system that parses the .xml settings file and allows one to choose which settings one wants to transfer should be implemented.
To be honest, I havenāt tried since. I simply did what Steve suggested above and copied over my entire settings.xml file. That seems to work fine, but of course it isnāt granular - you get all or nothing. I guess you could go about editing the .xml if you want to customize, but thatās a lot of work.
I have no reason to believe that OptionsImport has been fixed however, there is still a Youtrack item open:
Thanks Mitch, agree it would be nice to have the selective import work again. @stevebaer - would the xml copy method work for copying settings between V6 and V7 without a major mess? Up until now I was counting on OptionsImport but seeing that itās broken/obsolete I am trying to find a better way to migrate from V6 to V7 retaining all of the custom settings.
I would recommend backing up a copy of the settings xml file first and then copy the V6 one over. I wouldnāt expect problems, but if you do it would be easy to roll back by using the backup.
I tried copying the settings.xml file as a ātemplateā for new users in our firm. It worked for one user like I would expect. Then another user tried it and it properly overwrite the xml file with the new one, but when they ran Rhino, it overwrote it with their old settings.
Is all I need the 'settings-Scheme__Default.xml" file? or are there other files that I need to overwrite?
If they were running Rhino with a different scheme, copying that xml file wouldnāt do anything.
You write that, when they ran Rhino, it overwrote the settings - how do you know? Did you check the xml file before and after running Rhino and saw that it was changed the moment Rhino was run?
-wim
I did verify that the āsettings-Scheme__Default.xmlā contained the ānewā settings before running Rhino. Then after they opened Rhino, it changed the āsettings-Scheme__Default.xmlā back.
I assumed since it overwrote the āsettings-Scheme__Default.xmlā instead of creating a new xml with the new scheme name that they are not using schemes?
I installed Rhino 7 on my Windows 10 laptop a few months ago but since my settings did not automatically import I kept using Rhino 6 and only now got around to figuring out how to import them.
When I opened v7, the command panel was gone! (How can that even happen!?) Thereās no menu command I could find to unhide it. So I used this threadās suggestions, and they worked, but I think maybe some clarification would help others who like me are not as adept under the hood:
There is no single āsettings.xmlā file, rather a folder called āsettingsā with two .xml files in it: C:\Users[user]\AppData\Roaming\McNeel\Rhinoceros\7.0 [and/or 6.0]\settings. (Note āAppDataā is hidden by default in File Explorer)
Yes there is, itās called CommandPrompt - follow the options (Show/hide etc.). Itās also available via an Options>Appearance checkbox.
Yes, but the main settings are in āsettings-Scheme__Default.xmlā. It is possible that the window positions file might have info that the command prompt is hidden, but I didnāt find that entry.
I wanted to provide an update for my specific issue above (copying the xml file not working) - The issue was 100% on our end. It was all how our VDI manages the appdata folders. The solution that fixed it for us was to copy the xml file when Rhino was running. Then all was good.
To help others here is exactly what i did that works:
1-I got my personal Rhino exactly how i wanted the template to be.
2-i copied my settings xml file to our server. (the xml file in windows is located here %appdata%\McNeel\Rhinoceros\7.0\settings )
3-I then edited out a few lines to remove my recent files
4-for users i have them run a bat script that backs up their settings file, then copies that template file to their settings folder. They way our VDI is set up, they need to run the script while rhino is running.
the bat script i created:
robocopy.exe "%appdata%\McNeel\Rhinoceros\7.0\settings" /e "%appdata%\McNeel\Rhinoceros\7.0\settings\backup"
robocopy.exe "\\Your Server Path To The Folder With The Settings File" /e "%appdata%\McNeel\Rhinoceros\7.0\settings"
