UI and settings
Hope to be able to decide when I save settings. Overwriting settings on exit is tough to manage with multiple instances. I had to write a kind of mutex to prevent settings files to be modified unless I decided to (instance saving first locks out others from further modifications). I suggest an option which allows us to choose among “save on exit”, “prompt”, “never” and a command to save them. The same logic used at the very end of a rhino instance. Working with multiple monitors still shuffles UI positions and there is no easy way to recover it when we know Rhino will overwrite settings knowing the environment is messed up.
I want to mention that even if I’m working with Rhino for many years now, I can’t quite understand how settings are handled. Toolbars(rui, user managed), docking positions(xml, app managed), options(app and user managed)… I usually like to have more control over configuration but for the moment I’m confused. Too many dialogs, too many files and too many locations. One panel to manage all settings through option window maybe ?
Layout
I use several arbitrary paper formats and had to write a script to print multiple layout of different format in a single file. I can select which page I want to print instead of typing it (print dialog:multiple layout text box). I can set layer on/off and paste in selected layout.
Options the new layout panel could offer.
Model and Layout spaces.
We can’t lock layouts from being modified. Which is painful to address. Model space layer visibility is overwriting layout space. The way I managed this through python script:
save layer states before switching from model to layout space
turning on all layers (model space)
new layers are off (layout space) by default in existing layouts
restore layer states before switching from layout to model space
I hope this could be alleviated soon. My python script make rhino crash while grasshopper deals with layers (pipe object). Otherwise the sequence seems to works.
Named Selection
I did not understand that new panel. Since I was using named position to do it.
I think less panels with more options is easy to manage and it leaves space to viewports.
Floating viewports
A command to hide/show all floating viewports is really usefull. I do it with autohotkey for the moment.
Hello - thanks for the comments I am not sure about the above - is that a single issue or two? I think I undestand that you want to be able to completely lock layouts from any modification, is that correct? But the layers - you are correct that model space ‘non-visibility’ always trumps the detail’s layer visibility. That is a layer must be visible in model space if it is to be visible in a detail.
I am also not sure I understand the comment about Named Selection sets. I’d agree that it is not ‘mature’ yet but I am not clear on how it is tied to named positions.
I guess it is one issue. Model and Layout spaces may be more intuitive if they were completely independent. I’m not supposed to think about layout while I’m modelling. Actually, when I modified model space layers (visibility or adding new ones, (removing is not an issue)), it, most of the time, demands a lot of verification before reprinting layouts cause some of layers are off (forced by model space) or new layers show their content which were not there during previous layout creation.
Maybe something I don’t get in the way Rhino team conceived it. The way I see it, model space should not be considered at all in layout edition. Does it make sens ?
named positions vs named selections
I currently use (not a lot) “select in document” command in context menu of a named position.
Here my proof of concept in python.
Any feedback would be really appreciated.
At least knowing if the method used may be more robust.
Lately I had no flaw but with bigger Grasshopper project few crashes happened.
save layer states before switching from model to layout space
turning on all layers (model space)
new layers are off (layout space) by default in existing layout details (hold shift to leave it on)
restore layer states before switching from layout to model space
I sincerely hope McNeel puts focus on these issues in the next version, because 2d/layouts could/should be so much more effective to use, and it’s not much that is missing (at least it looks that way).