Save settings without closing Rhino

Continuing the discussion from V6 centralized recent file list:

Making a new thread on this one, what would you expect to happen if there were multiple Rhinos open and you saved settings in one via a command (this is the idea right?) and then closed another session after that which had different settings. Right now, the last closed Rhino indicates the personal preferences but I wonder how that would be effected by the inclusion of a command to save settings without a close… may get confusing or maybe I’m just confused about the request :wink:

1 Like

Possible solution idea:

  • Have the manual save preferences command change the settings
    immediately in all other opened files too
  • Have the manual save pref. command turn of autosave of preferences for as long as you have at least one rhino running.

I get very annoyed/disappointed by every time that I make custom buttons with icons, large commands under them etc. that I don’t think about the “Close order” of my rhino’s, and then they just disappear.


the analogy or parallel here is what its like to work in other apps that allow working on multiple files at the same time. The Adobe CS lineup for example. Of course its just one instance of Photoshop that is open, but we can have multiple files open. We don’t have to worry that the brush size for one file we’re retouching will be different for another file. We can change the brush size once and have that same brush size throughout the session.
I know Rhino doesn’t follow this method. I know the multiple instance method has its advantages at times. To offset some of the negatives I think something like Peter’s suggestion would be great. If we make a settings change, or a button macro change in one instance, I want the choice of saving that change to all of the open instances of Rhino.

Thanks all for the time in thinking about this one and the suggestions. I’ve added a usability issue (RH-23114) to our lists and will try and get a dialog going about what to do here. The issue seems common enough for the multi-session crowd that we should try some potential fixes. I personally like the idea of overwriting the prefs and updating the UI for all other open sessions if possible but we’ll see if that’s technically possible with the current architecture.

1 Like

How about having each instance check the RUI when closing against the RUI that it opened with, and if they did not match,report that with a dialog “External Toolbar settings file has been changed, preserve changes to settings or overwrite with settings from this session?” The dialog would have to be smart enough to not appear if the changes were from a manual save in the current instance, so you wouldn’t have to remember in which instance you most recently made changes.

I keep my RUI in my Dropbox, so it syncs over multiple computers, and if I have left a file open on the work machine and want to make changes at home, there is no easy way to save those changes (I can log on remotely or rename the RUI I suppose, but that’s not much of a solution). Looking at my Dropbox, I currently have nine conflicted RUI/TB files left over from getting snagged by this.

I would not like the afterwards dialog I would not like to have to go trough all those dialogs at the end of the work session/day etc.

I prefer the on applying new settings dialog to choose where you want to apply it. See my first post in this thread for examples.

Just a couple of things to note:

You CAN save your settings (some of them anyway, like toolbar changes) without closing Rhino. I have had the alias “sw” (“Save Workspace”) for years:

! _-Toolbar _Collection _SaveAll _Enter _Enter

That will save all your open /rui files in their current state without closing Rhino.

However, if you have another open instance of Rhino, closing that afterwards that will overwrite the changes, which is why I make sure I only do workspace editing with one Rhino open. It’s now an ingrained habit.

IMO, tho only way to change this would be to entirely remove the automatic overwrite of workspace files when Rhino closes. It could be replaced by a warning dialog if something had changed - similar to the one that already exists when we close a workspace file (see image attached). However, that will certainly be annoying to some.

Note also that there are a host of other settings that ARE saved instantaneously per open instance - such as various command options, etc. And, as Rhino also allows you to have different schemes, there are a lot of options that are saved by scheme, and different schemes do not overwrite each others settings.

With something as complex and open to customization as Rhino, no matter what is done, you can expect that it will work well in certain situations and less well others. That is just the nature of the beast, IMO, I don’t see an easy way to accommodate everyone’s way of working without running into complications somewhere.