I am working on a specific file, I change my windows, my layer’s panel width. etc. I don’t want that exception to become my norm. I have my saved preset for that and if I want permanent changes I should edit it and rewrite it or save another version.
This is just beyond ridiculous to me. In all software, you are often ASKED to commit changes.
But this ‘change and it sticks’ really has to go. Defeats the whole purpose of having a saved preset.
Thanks.
In V8 I think saving different UI arrangements as named window layouts should allow you to easily switch between your different custom layouts.
Did you try loading your preferred layout at startup?
I have created and saved custom layout and reset it that way.
But the fact that Rhino keeps prioritizing custom non permanente changes to it and remember it for next session is annoying.
AFAIK Rhino has always saved things the way you left it in the last session you close, if it worked correctly.
The fact that you can now save different layouts should not change that behavior imo.
You can make a startup script to set the layout to your preferred default if you prefer it to always be reset back to a saved layout.
Well that is the crux of the issue. Before, it made sense, because you could not save a custom layout.
Now that we can, this function is conflicting with the current state of things.
We don’t need this function any longer. If an user wants to permanently change their start up layout they can just edit it and resave it.
Having got to a layout I like I seldom change it. If I do, it is for a temporary change to facilitate an unusual task. If I’ve finished the task, I change back to my standard layout and carry on. Next time, Rhino will start with my standard layout, so no problem. If I haven’t finished the task I am grateful that Rhino will start my next session with the temporary layout so I can complete it.
I get that you don’t like this, but I do, so please don’t say we don’t need it.
Regards
Jeremy
It goes beyond personal choice.
Is it factual we don’t need an old feature when a superior one has been implemented.
Rhino should not alter the startup layout unless the user explicitly commits those changes. Temporary adjustments should remain just that—temporary, not permanent. This issue arises from having old features (that made sense in the past) not being retired in spite of the new capabilities in updated versions.
If you already have a startup layout saved, but made custom changes to it and want to keep those too, can you save it with another name and have 2 saved layouts. The startup and the startup edited.
So it is a fact we don’t need it. Maybe you want it because it is more comfortable to you, but again, it is just a save, it will not take you more than 10 seconds.
Also, it even makes sense to save it for a later use, that way you can keep making custom changes to the interface without the worry to loose your preset.
It is just basic stuff to be honest: It is easy to to make unintentional changes to UI and others when working.
This is why, in 99% of software, if you make changes to a file and close the editor without saving, those changes are not kept when you reopen the file. The changes are considered temporary until you explicitly save the file. This behavior ensures that only intentional, committed changes persist, preventing accidental modifications from being saved permanently.
I make custom changes to layout when working almost daily. Sometimes a layer name is too long, so I enlarge layer panel.
Sometimes I work with materials so I position the material column in layers panel first. Sometimes I work with printing widths so I need that closer. Other times I need to maximize viewport so I decrese the size of everything else. When it comes to snaps I change them all the time when working.
What makes more sense?
A. Having to reset my layout every time just before closing Rhino so that it goes back to default, basically adding an extra task just before every time I close Rhino. (your suggestion)
B. Close Rhino and have it automatically reset to the default I precisely set because it is the most generic and flexible state for the work I do?
I do not agree with you.
Having to remember to save a changed layout after each session would be a big change and would cause the lost of a lot of work.
There is not a thing factual about anything you are asserting here. It’s not based on any logic besides “this is something I’ve got in my head that I would prefer, I think.” There’s no basic principle of UX Design like Fitt’s Law to guide this, it’s just like, your opinion man. Whatever basic principles exist(that I read like 25 years ago)would say that adding interface elements to manage your interface is a sign of utter failure, and that allowing users to waste time on customization is mostly a mistake.
Do some actual A/B testing with a few dozen users for a month and get back to us.
You saying so does not make it so. You need to use arguments if you want to counter mine.
There is plenty of good practice laws in UX design. It is not all preference.
In most cases:
-Not committing changes unless specifically confirmed by the user.
-Temporary changes not taking precedence over defaults.
-Not forcing user to reset back to default everytime, when the user has already set a default (it violates the very definition of default)
The list goes on and on.
A/B testing is often used to test performance, it will not serve any good in this case.
The list of stuff you pulled out of thin air goes on and on. Sources please.
What? Remembering to save changes is a big deal? We have been doing this for almost half a century now?
Anyways, I don’t think you need to save every single little change you make to your layout.
You seriously need a ‘source’ to tell you that the not respecting an user set default is bad UX design?
What source do you expect me to provide? Like a scientific paper? Are you serious right now? 
Well yes, really. I’m super sick of UI requests and debates as no one actually knows what they’re talking about and can’t justify anything. It might as well be Twitter.
Your whole mental model you’ve based this request on is obviously completely different from say Marc’s, the idea that there is any “default” that you want to “save” beyond the one that comes out of the box is NOT a “fact.” Everyone who is baffled by this request just wants Rhino to stay how they left it. That’s an entirely sound concept. Adding more interface to allow for more subtle granular control over that is something someone might ask for but it’s hardly urgent and needs to be justified with ACTUAL TESTING.
I have to agree here. Rhino’s UI has been messed up since V3.
Workspace changes in one file should not be a default when you open a new file. Blender for instance only saves a workspace change into your current file if you save that file not to your default workspace which you save by clicking save preferences. So when you open a fresh file it only opens your saved preferences not your last open files layout. I like this behavior better than Rhino’s current behavior.
And worse Rhino should not hose and not remember your layout when you crash or worse the occasional opening of Rhino only to find all your toolbars and sidebars set back to default for no reason.
In other programs take Blender you get to save your layout and Blender remembers it if you crash. What does Rhino do it reopens with the default workspace, this doesn’t make sense.
In Unreal if you crash and reopen the file, Unreal actually remembers what tools you had open when you crashed and asks you if you want to reopen them. What does Rhino do? Rhino reopens their workspace not your saved workspace with many of your customizations gone.
The way Rhino saves on default and the current complexity to make changes makes it really a bummer if you crash. This has been going on for years.
I use Cakewalk and their options for customizing and going between layouts and tools was lightyears ahead of Rhino. Why can’t the developers look at other programs that are better in this respect and try to emulate what’s best?
I think Shynns’ request would help bring up our saved workspaces instead of Rhino’s default when we crash. I’m tried of having to reset all my side bar tabs and other customizations when rhino crashes. For me it makes mores sense to have a workspace remembered in a file and not as a default that carries over into a new file unless you want that, then you save that as your ws preference.
RM
Oh but it is a fact since the introduction of custom layouts in Rhino 8.
It is only natural for a user to want change factory settings and have a custom default. It is standard practice nowadays for software to enable this possibility.
I think I am justifying things pretty solidly with arguments, reason, logic, examples, analogies and definitions.
Asking a ‘source’ for a logical argument is simply ridiculous. It is like asking for a source on why killing is wrong. You cannot scientifically argue every question.
That goes against the idea of defining a custom layout. You see how Rhino is conflicting between both worlds after the latest update in Rhino 8?
Why would I have the tool to define a custom layout, by saving it, if Rhino is going to default back to the latest state anyways? Huh?
I think being able to save multiple custom layouts and restore or switch between them is a step in the right direction. But users should have the option to leave their workspace LOCKED from any further changes. How is this not logical to you?
Why would you want that? You have no idea what you are going to be working on tomorrow and what tools you might need to use. In what scenario do you need to keep making constant changes to the layout and keep those changes? Most people don’t even customize their workspace. And you are talking about making such relevant changes every single day that you want those changes to stick because you know in advance those changes are going to be useful for the day after??? Who are these fortune tellers who can know exactly what layout they are going to need the next day??
What if you want to go back to a previous instance? It is forever lost?
I refuse to believe people like the idea of having their room be left a mess instead of taking advantage of the virtual marvels of software such as Undo and Reset. Instead of cleaning up you would wake up the next day and your room is completely cleaned and organized with everything in its place.
And if some love chaos, let’s please not design with them in mind.
This is a very specific layout that was useful to me in a single day during a very specific moment in time. Do you think I want this forever? NO. I want my Rhino to default to my custom default dammit.
Agree.
Cinema 4D also works the same way too.
-You have some presets that come with the program.
-Then you can define a ‘startup’ layout.
-You can create additional custom layouts.
-And you can even lock the layout to avoid changes to it.
But none of the changes are committed unless you ‘save layout as’ and overwrite your file.
You’re obviously not asking that sincerely. I’m done with you.
No I am asking seriously. There only two possibilities:
A. Either you know you will need that custom layout because you are not yet done with the task. (like @jeremy5 said)
or
B. You don’t know because you have no idea what you will be working on next.
In case of B, if you have no way of knowing if that specific state of things is going to be useful for you in the next session then it is only logical to go back to square one and have Rhino reset the layout back to your custom default or the default if you have not defined a custom one.
In case of A, that is you know for certain you need that exact layout because you know you will be working on that same task for several Rhino sessions, then you can just save the layout and name it say ‘subd modelling of plane’ for instance. This way you can have this layout available for as many session as you need until you complete the task.
And what is more, a plus, in the distant future, if you ever need to repeat this task, you will have your custom layout saved ready to go. On the other hand, with your current method, after several days or months, you would have already made custom changes to it and lost it forever.
This approach provides the most flexibility, ensuring that the software can accommodate the widest range of users. That is in fact, why, many software choose to do it this way (blender, unreal, cinema4d, and others).
