Is it possible to have several files open in one single rhino instance? This seems to be the case on macOS. Under one Rhino6 app instance, one can open multiple files and switch between them. But in Rhino6 on windows, the default is that each new file that is opened or created closes the previous one. I’m haven’t found an option to change this behavior, but maybe I’m missing something…
You’re not missing anything. That’s the way Rhino for Windows works, each document is a separate instance. I do not see any advantage to an MDI (multi-document-interface) à la Mac - especially when you consider that if you crash one instance, they all crash, which is not the case under Windows. You can have as many Rhino instances open as you want at one time (I typically have 3 or 4).
To switch between Rhino instance windows, there is always Alt+Tab or the taskbar buttons.
There are multiple applications that I use in Windows that use the MDI (Autocad, all Affinity and Adobe) but I don’t care about that discussion. My only problem with this way of working is that it takes really long! Unlike Excel or Word for instance, that when you open a new file a new instance of the application is spawned almost instantly. With Rhino, I have to explicitly go and open a new instance of Rhino and it takes really long because it insists on opening on loading VisualArq and Grasshopper everytime.
If a document is not saved at least once, yes, that can happen - as there is only one ‘generic’ autosave file. So if you have two or more unsaved documents open at the same time, each time Autosave kicks in, it will overwrite the existing one, which could be from another instance.
Once a file is saved, it gets its own autosave file attributed to it with a name, so it cannot overwrite another document’s autosave.
Lesson #1: always name and save your file at least once (if it’s important)
Lesson #2: never rely on autosave as a substitute for actually saving a file - that’s just bad practice and especially with how the Rhino autosave system is currently set up.
Note the above applies only to Windows - Mac is completely different due to Versions.
@Brian While the basic design of Rhino’s approach to “MDI” is, IMHO, quite sound and quite handy, I think Filipe raises a very important concern. His Office counterexample makes Rhino’s loading speed seem especially egregious. Couldn’t you put some time into finding a loading approach that solves this issue? (I know that V7 seems to load a bit faster, but it would be nice if it were even faster, like the office apps.)
Mitch points out another area of possible improvement in the way autosave overwrites multiple unsaved files. Although placing the onus on the user is convenient for the programmers and keeps the users on their toes, perhaps some creative thinking here is in order.
That one minute doesn’t have to be wasted time: you could use it to think great thoughts, stretch your back, refocus your eyes or even whip open an Office app and check your mail.
But if someone can’t make productive use of their minute, and they regularly need multiple instances of Rhino open, they could write a script to open half a dozen instances at the start of the day while they make coffee and have a little herd of Rhinos sit there awaiting their summons.
That part might or might not work - I often wait for Rhino to open and try to just write something in another document, but Rhino opening steals the focus several times during the opening process and the result is what I’m trying to write in the other document goes to the Rhino command line…
My base Rhino 6 takes about 8 seconds to load here V7 maybe a tad faster, but it’s true that some plug-ins - RhinoCAM and V-Ray are notorious - stretch that out to 30 seconds or more.
Not really. If the slow loading comes from having third-party plug-ins and GH components loading, then the responsibility is shared with all those developers that do “just one little quick thing that takes less than 3 seconds” at startup. Plus the few, like Mitch mentioned, that take a relative eternity to start.
Another place where we just can’t win. When we fix this focus-stealing problem, another group of users with pitchforks and torches comes running at us with “Why doesn’t Rhino show up on top when it starts - I just started it, after all!!”
I totally agree and also understand that with great freadom comes great responsability (and work). We have this amazing ecosystem of plugins that we can collect and use, so a little responsability for what I put in my Rhino also lies with me. And I’m also one of those adding just another 3 seconds.
So I’m not really the pitchfork kind, I’m just looking for solutions. For instance, a way to avoid loading grasshopper with every second or third instance of Rhino I happen to need. Or more simply to just load Grasshopper and its plugins when I call _Grasshopper command.
Grasshopper doesn’t load with Rhino. You have to run the Grasshopper command to have that happen. Perhaps you have it as a startup command? Or perhaps you have other plug-ins that are taking all the time to load Rhino?
Hi - As Brian notes, in factory-default Rhino, Grasshopper doesn’t load until you run the Grasshopper command.
With vanilla VisualARQ, Grasshopper isn’t loaded until you either start a VisualARQ command or load a file that is based on a VisualARQ template. VisualARQ comes with its own scheme so you should be able to avoid using the plug-in - and thus triggering a Grasshopper loading - if you don’t need any of its functionality.
Thanks @brian and @wim, I missed your reply. Yes, that is what I was used to. I don’t use a VisualArq template…so I’m guessing VisualArq is somehow triggering the load. Is there anyway of resetting to default? If there is not I’ll soon move to Rhino7 anyway.