Thanks for the Settings Editor!
I take it that this will be a place where eventually all settings can be managed. As such, I am missing the “DeselectOthersBeforeSelect” setting that can be reached using the -SelLast command.
Thanks, we put quite a bit of work into a completely new settings system for Rhino. Try this; open two V6 instances and change a setting in one (something like a color in the UI). Now close the options dialog and watch what happens with both of your running Rhinos! This should eliminate the problem where you forget which Rhino you made changes in and accidentally shut down the other one last.
So you want all sticky settings editable in the editor (radius in the circle command for example)? Command options were not planned on being part of the settings editor. That would actually be really hard to implement given how our settings system is structured. That said, there are probably many commands and command options which should have always been top level ‘settings’. We can try to identify these and convert them to ‘proper’ settings that you can edit with the editor. We just need to know which ones are important to you guys.
1 Like
I think there’s at least two possible design philosophies here.
First, there’s the one implied by your answer: make only the “important” ones available on a central editor - along with requiring the user to memorize which ones are on the page. Would my important ones be anything like yours?
The other would be to include ALL options of a certain clearly defined type so that a user who becomes familiar with the classification concept can reliably find what he needs on the editor form. It would become the “goto” form even for those options which are not frequently changed and would need to be searched for otherwise.
I think I’m doing a poor job of explaining what I’m thinking of. I’m thinking of ease-of-use, intuitive workflow, especially for lesser used options. Designing a working environment that seems to “always work the same way” across as broad a spectrum of operations as possible. Minimizing the number of fundamentally different ways that users talk to Rhino, so that when a user is in a less familiar area of Rhino his “hunt and peck” journey throughout the possibility set is short because the number of fundamental ways of doing things in Rhino is small.
I think this approach would also simplify programming, since under OOP concepts a few basic interaction schemes could be implemented in general, then just tuned up for specific tasks through inheritance.
I’m not saying that Rhino today is “awful” in this regard, just that it could be a lot better.
Or am I, like Bob so often says, “confused”?
The editor does include all options except for command options that stick between sessions. An example of a command option would be the radius option in the circle command.
I think it is really an issue of feasability for what we can accomplish. In order to get every sticky option for every command listed in the editor, we would have to rewrite all of those commands in a different way (and so would every plug-in developer). This is something we may eventually be able to do, but I don’t really foresee that in the near future.
Maybe you are ‘confused’ 
Have you looked at the settings editor? What you are describing is pretty much what we have. All of the settings in Rhino and plug-ins are listed in a consistently named way.
Well, you caught me. I am only just now installing the WIP. I was responding to the words in your post, notably the part about “identify” and “which ones are important”.
I look forward to seeing exactly what you’ve done.
Yes, that will definitely help! Thanks again!
Yes, I guess that would be the way to go. In this case, I feel that DeselectOthersBeforeSelect is such a top level setting. (Additionally it’s a bit hidden since you have to run the dashed version of the command). I’m sure you have it noted down in your system somewhere that some user felt it important to have the radius of a circle to be sticky across sessions 
but this is typically a setting that gets changed many times during the course of one single session.
Related: I wouldn’t mind that Rhino kept track of which commands (and in-line options) are used and that anonymized aggregated information on that is sent to McNeel - a system that the user would have to turn on actively. It would probably help identifying trends and also help answer questions like this on. My 2 cents.
We do some of that already to a limited extent. We try not to collect information unless we have a question we’re trying to answer. In this case, collecting every command and every option used by every user generates tons of data. Mining that data is challenging, though many people (Google, Amazon, Microsoft, and others) are making it easier every day.
Yes, I understand that it would amount to huge amounts of data if collected from all users. I would think that most would leave it off though. I guess that might be a problem in itself as it would bias the information towards a specific type of user. Hmmm…
Perhaps it should be mandatory on during a WIP stage… That would lead to a more controlled amount of data but, I suppose, would still bias the information - but not necessarily towards the same type of user.
Oh well… 
Here one can see changes register but whatever I do gets reset when closing the dialog. Test case: Changing axis colors in viewport corner – no chance to get this to stick. Running as admin, if that matters.
I can repeat that and have logged it as a bug.
http://mcneel.myjetbrains.com/youtrack/issue/RH-29279
@JohnM can you take a look at this?
Thanks Steve. Just to be clear: The axis tripod was just a sample – nothing I set inside this Editor seems to stick. Whether I change the color of selected items or the GUI font… it all gets reset.
@Steve I was able to reproduce the XAxis color problem and am looking into
the problem now.
1 Like
I was able to figure out what was causing the settings not to stick and fix the problem. The fix should be available in the next Rhino update.
1 Like