So Rhino killed my Layout again... :-(

Today it happened again.
I updated my Rhino 7 installation on my laptop while Rhino was also running on my main machine but minimised. When I came back to my main machine, the license requester was up, asking me if I want to continue using it on this machine, which I said yes to.
When I un-minimised the window, I got this:

All my carefully laid out panels were filling all of the screen…
Now this is the second or third time this happened (can’t remember the circumstances from the last time) and I had smaller issues with things getting out of whack every now and then.

So I want to ask: Is there a way to save a screen layout of toolpanels a reliable way?
To my great surprise I was unable to find one, although this feels somehow basic.
It takes a long time to put it all back to how it was, so I’d prefer not doing this regularly…
And I had it also happen to me that it didn’t “take” when reordering things and after a restart it was broken again.

So yeah, sorry if this is obvious, but I didn’t find a way to do it…

Thanks a ton!


1 Like

I’m confused how this could happen.
Here’s is something to try:
After you get a single Rhino setup like how you want, close Rhino, and make copies of these 2 files:

  • %AppData%\Roaming\McNeel\Rhinoceros\7.0\settings\settings-Scheme__Default.xml
  • %AppData%\Roaming\McNeel\Rhinoceros\7.0\settings\window_positions-Scheme__Default.xml

These are the files that store that information.

Then if this happens again, please send us copies of those 2 files in their current screwed up state, and them replace them with the copies you saved that are good.

Perhaps with the before (good), and after (bad) versions of those 2 XML files, we might be able to guess as the cause.


1 Like

Thanks a lot John,

but are you saying that there really isn’t a way to save a screen layout? That somehow feels weird for a freely customisable GUI like Rhino.
For instance in Houdini I can save my current setup in a list and select other setups from that list for different tasks, so it’s not just about not losing my setup or transferring it to another machine, but also having different setups for for instance SubD modelling vs. texturing etc.

If that really is the case, I’d like to make this into a feature request.
Since basically those files you mention already exist, it should be possible to make that a fearture instead of just a hidden workaround.

I’ll check out those files and see what I find.

The issue in the past was always connected to having Rhino minimised or using different, non full screen sizes and toggling stuff. Sometimes the panels just got different sizes from what I had set up initially (and the way they work its rather cumbersome to set up) and two or three times I got this totally unusable state that completely hides the viewports.

This time it happened like I described above, having Rhino minimised on one machine, updating another, and later coming back and clicking the license requester yes button.

Will come back if I find anything interesting…

So back to fiddling all that stuff back and hoping it’s saved and recalled correctly afterwards…



This is how my screen normally looks:

Is that position data only saved on close or is there a way to force Rhino to save preferences and this screen layout data?

Like I said, I had it happen before that closing Rhino and bringing it back up after such a destruction of my layout did not correctly restore it and I had to do it several times before it stuck.



Rhino saves your settings each time in those XML files.
We do not have a system for saving and restoring different names setups.

The mystery here is we do not know what is messing with those files.
That’s why I suggested manually saving them to make restoring them relatively easy.

If you can figure out a pattern when they get screwed up, we might have a chance on keeping it from happening.

With “each time” you mean when I close it or what “time” would that be?

I don’t think anything is messing with the files themselfes, I think Rhino (while running) screws up the layout and that is getting saved.

Will it help you if I send you the before and after files via PM?



I suspect some event; maybe having too many files open at one time, is messing up the XML files.

You won’t know until you close and restart Rhino.

If you have backup copies of the XML files that are good, when you discover the problem, save the existing screwed up XML files to send to us.
Then copy in your backups, and send us all 4 files.

Well, I had a single instance of Rhino 7 open on the machine this time.

The “event” that broke it this time was that license requester with Rhino minimised IMO.

But yeah, it’s possible back when I didn’t save correctly after adjusting that I had multiple instances of Rhino open. Funny that you do not have a more elaborate way of handling layouts. I don’t think I’ve ever used another 3D application without such functionality.

I have now copies of both versions and will send you a PM if that is possible here.



1 Like

And it happened again.
This time nothing untoward happened before, I just closed Rhino which was fullscreen.
Opened it again and bam - the whole layout fucked up again.
The only maybe somehow unusual thing was, that I had the Octane render window open but minimised.

This really feels like something from Windows 95 times.

Jesus, how can a software like Rhino not have proper layout saving and restoring capabilities in 2021. You have all this complex window placement stuff, everything can be customised, but to “save” it I have to fuck around with some obscure files somewhere.


This is really driving me up the wall.

Come on, you can do better.

Thanks and cheers,


Hi John,
What are the corresponding files for Rhino 5?
(those two xml-files seem to exist only vor version 6,7 and 8)
Rhino 5 (which I still use alongside all newer versions) is notoriously haunted by this phenomenon.

1 Like

I’ve seen this multiple times. I remember back a few years ago that one lady working for me had her layout messed up every morning. She was convinced that someone was screwing around with her on nights for some kind of vendetta (if you knew her, it might not have been a stretch believing that). So one day, after she left I changed her password so that if she had exposed her password to the people on the shop floor they would no longer be able to mess with her Rhino. When I came in early the next day, logged in with the new password that only I knew, sure enough her layout was jacked again. I reinstalled Windows and the problem never happened again, not even a single time. So it seems to me that issue was not a Rhino issue, it was a Microsoft issue.

Here’s another anecdote. During the Rhino 6 era, I had a guy working for me that never had a single issue with his Rhino layout. Then he requested a third monitor, and once it was installed his layout would no longer save correctly. We run with Filters and Osnaps docked on the left and right of the command line. Every time he opened Rhino after that those two windows would toggle sides. I never was able to solve that one, but I would bet money that a fresh Windows install would have fixed that. The employee retired, and his computer was re-formatted for a new employee. Guess what happened? It falls under the “no news is good news” category as I’ve never heard a single complaint about that computer to this day. So a Rhino issue, or a Microsoft issue?

I still have about 6 (out of around 170 installs) that still exhibit this behaviour, I’ve offered to have their computers re-formatted and Windows reinstalled, but they say they got used to it so don’t worry about it. I’m pretty sure that would solve their issue because it did in the past. But no one really wants their computers reset to the default, so we left it alone.

It is annoying, I agree. But the cause may not all be Rhino’s fault.


I don’t think it is a Windows issue. I had it just the same on a fresh windows 10 installation as on a 9 year old Windows 8.1 installation.

I think more and more that it has to do with a.) opening more than one Rhino instance (which I do a lot) and b.) having windows minimised when closing them, even if it’s not the main window but for instance a renderers window. So the latter happens quite often too here.

It’s definitely not happening constantly here, otherwise I would probably give up using a custom layout altogether.

But it still stands, that for a software like Rhino with a very customisable GUI, it is unbelievable that it doesn’t have a proper way to save, load and exchange custom layouts for the GUI.
In any other 3D application I use it’s a given that you can switch between layouts optimised for certain tasks.
And since the basic building blocks are already there in the form of those XML files, it would probably be relatively trivial to make this into a feature, by simply saving them into different folders for each custom layout or something like that.
And then have a menu entry to select between them, save an existing or new one etc…
Users could exchange interesting layouts and if a layout breaks, you would just reload it.



P.S. Take a peek at SideFX Houdini if you need inspiration, they have it right :wink:

1 Like

Hi Dan :slight_smile:

Well … let me look at it from a different point of view.

We are scriptpers.
When something in RhinoCommon or rhinoscriptsyntax doesn’t work the way we expect, we look for a workaround, we try to use a different method or try to code something different ourselves, if possible.

Windows may do weird thing (it certainly does sometimes), but it’s up to the software house to find a way to do what they want, possibly doing things in a different way.

Just my humble opinion. :slight_smile: