I thought it meant “settings altered from default” but one of my custom view modes is blue. The others don’t if I alter their settings.
Hello - I also see some do not turn blue and I can’t yet see what the difference is - all the ones that do not go blue are custom but some customs do go blue…
-Pascal
In V6, display modes (new ones) are now tracked based on which mode they were copied (derived) from… Which means that custom display modes now have known defaults (the values from which they initially started).
For example: If you create a custom mode by duplicating the “Shaded” display mode, then that means the defaults for your new custom mode are the same as the Shaded mode defaults.
Modes that cannot be determined if they’re derived from any other mode will simply work the way they always have (i.e. Restore Defaults does nothing).
The whole point of this is so that the settings and preferences dictionary, that is stored on your system, is reduced in size with increased efficiency… The only settings that get saved and loaded are ones that are not a default value. This means if everything is at its default values, then nothing will get stored or loaded from the dictionary. Since almost anything you do now in V6 can cause the settings dictionary to get saved and/or loaded, it’s important that this remains as efficient as possible. Display modes are quite heavy, and saving or loading all display modes simply because you checked or unchecked a setting in the Display Panel can be a huge time suck, depending on how many customized display modes there are.
That being said, since custom modes can now have defaults, the “Blue highlighting” mechanism just kicks in automatically. I can certainly disable it for non-built in modes if it’s something that everyone thinks should be done…but right now, I don’t see the harm in leaving it the way it is… So please, if you have reasons and examples (or simply just personal opinion or preference) tell us, and we can discuss turning this feature off for custom modes.
Thanks,
-Jeff
1 Like
Note: I’m only talking about turning off the “blue highlighting” for custom modes… Custom modes will still continue to track their derived defaults for reasons I mentioned in my previous post… So I’m only talking about disabling the UI feature here, not the tracking of custom mode defaults.
-J
I think if anything the highlighting as a misleading effect.
Seems to me that custom display modes will by definition have settings different from their progenitors. I’m not sure the blue highlight adds anything. But it invites the misinterpretation that it flags an alteration from some fictitious original state of the higihlit custom mode. It also suggests a typological distinction between them and pre-V6 Custom Modes which also seems misleading.
I think I tend to agree - only the default built in modes should show blueness.
-Pascal
Obviously… But that doesn’t mean those settings should now be considered the “Default”… Something has to start from somewhere. Users change the built-in mode settings all of the time, making them different from their starting value. If we never allowed changing the built-in modes, then I can see a difference… But as it is, Rhino has display modes, built-in or customized… and they all start from some set of known values…once you change one of those values, it is now different from the known value and thus some kind of indication can be made… Saying that “You changed a built-in mode value” only, doesn’t seem to be any different (to me) than “You changed a custom mode value”. One value is determined when Rhino starts initially, the other is determined when the mode is created initially (which internally to Rhino and the code, are both exactly the same thing). Granted, it means that almost every single custom mode will show blue in one area or another, since it’s most likely users will make modifications to it (otherwise, why create it).
At the very least, you can see exactly which settings you’ve modified in your custom mode, and exactly which values make it a custom mode. If you have a custom mode and it’s not blue, then you haven’t made any changes to it (unless of course it’s an old pre-V6 mode).
I think it “feels” different because it’s just not what you’re used to given the way things have worked over the years…which is certainly a valid argument.
Nevertheless, I will add code that prevents highlighting of custom mode changes, since it seems it’s going to confuse and mislead users…but as someone who constantly is creating and modifying display modes, I find it quite useful to be able to easily identify what makes “MyShaded” mode different than Rhino’s “Shaded” mode… Without the highlighting, that task is almost impossible to do at a glance, and requires a more tedious line-by-line item comparison process. Custom modes usually are made up of only a handful of changes…being able to see exactly which ones those are at a glance just seemed like something that would be pretty useful for most…I guess that’s not the case.
This might not make it into SR9, but I’ll try.
Thanks,
-Jeff
But why? Is it because you find it more valuable only knowing that you’ve changed a built-in mode setting? Do you not find it useful to be able to immediately identify which settings in your custom mode actually make it a custom mode? … Or is it simply just because that’s what you’re used to, and therefore that’s what you expect?
I make a copy of Rhino’s “Shaded” mode and I call it “MyShaded”
Now, how and why are these two scenarios different to you?
I uncheck “Show isocurves” in Rhino’s Shaded mode.
I uncheck “Show isocurves” in “MyShaded” mode.
I open up the Display Mode Settings.
In the “old way”:
I can see that “Shaded” mode is blue, and that “Show isocurves” is blue, thus that’s the setting I must have changed at some point.
I can’t see anything about “MyShaded” mode… The only thing I know/remember is that I copied it from Shaded mode, but I haven’t got a clue which settings I’ve modified.
The “new way”:
I can still see that “Shaded” mode is blue and that “Show isocurves” is blue.
But now I can also see that “MyShaded” is blue and that “Show isocurves” is blue…However, knowing that I made “MyShaded” mode by copying “Shaded”…it means I also know that “Show isocurves” is the only change I’ve made to this mode, and is what makes it different from the original (i.e. exactly what makes this a custom mode)
…now add to that more than just “Show isocurves” changes. IMO, this feature becomes more and more valuable the more changes that exist.
Why isn’t that useful?
Why is only knowing that changes to the built-in modes more useful than knowing about all changes that have been made to any mode?
Since I’m adding code to remove the highlighting, this is probably all moot…but I am curious why this isn’t considered useful…and would like to hear more about it.
Thanks,
-Jeff
Hi Jeff - yeah… I guess that does not seem all that useful to me, but maybe I’ve been looking at it wrong - (mostly I use the blues to help troubleshoot user problems relative to the built in modes). It seems odd, for example, to me at least, to blue-ify a custom mode that I create with New, as soon as I make a change in its settings. What is the blueness based on and what should I expect if I click ‘Restore defaults’? Even based on an existing mode with Copy - if the copied mode is not a default then my new mode is blue right away before I make any changes… what does this mean?, I ask myself… if I restore defaults it goes back the default state of the copied mode, not the state of the copied mode when it was copied, if you see what I mean. So it’s all just a bit jumbled…
-Pascal
Nevertheless, you should probably keep the old code around for reversion when V6 users start encountering the reasons you think it was a good idea. 
1 Like
“Custom modes usually are made up of only a handful of changes…being able to see exactly which ones those are at a glance just seemed like something that would be pretty useful for most…I guess that’s not the case.”
A strong case. But once a mode is so different that it doesn’t resemble its progenitor, a user may not know what to expect in the non-highlit fields, as the progenitor may not be identifiable.
I’m new this year to Rhino. I think others are better judges of how it could best work…
But what are the settings that you start with? Have you ever wondered what those are and/or where they come from? If you create a new mode, and do nothing…what do you get? If you then start making changes to the new mode, then what is it you’re changing from? It turns out, you’re changing from the canned defaults Rhino uses internally (see my next reply)…
Again, what is it you’re seeing with built-in modes that you’re not seeing here with custom modes? The “blueness” for built-in modes is based on what? If you can answer that, then you can answer your own question above?
What did you expect to happen before when you clicked “Restore Defaults” for a custom mode?
Every single display mode starts with initial values…for built-in modes, we chose what those should be… But for custom modes, what are those initial values? The answer is: Whatever values I came up with when writing the code for the base class display mode…which is pretty close to what Wireframe settings are, which IMO can make things even more confusing when trying to create new “shaded” type modes…
For example:
In V5 if you made a copy of Shaded mode, then setting your view to that new mode would give you a “shaded” view… However, if you then go in and click “Restore defaults” for your new mode, guess what…your view will now show as Wireframe… Is that really what most would expect or want?
The way V6 works (atm) is that it now bases its defaults from the mode from which it was copied… If you don’t create a copy and just create a new mode, then the defaults are what they are today (Wireframe). But if you copy from an existing mode, then the defaults will be based on what the copied mode defaults are…If the mode being copied is not a built-in mode, then the defaults will be based on whatever the copied mode defaults are based on, and so on and so forth… basically, the defaults will eventually be narrowed down to one of the built-in modes.
For example:
I create “MyShaded” by copying “Shaded”.
MyShaded defaults will be the same defaults that Shaded uses. Which means my V5 example above won’t jump to Wireframe when you poke “Restore defaults”, and will indeed remain “shaded”.
If I then create “MySecondShaded” by copying “MyShaded”,
Then MySecondShaded defaults will be the same defaults that Shaded uses, because it’s derived from MyShaded, which was derived from Shaded… I’m probably making this sound worse than it is…All that is happening is that Rhino is now keeping track of which modes were copied from which modes…so that it can eventually track down a built-in mode to use at its defaults.
Let me try explaining it using UI…
Suppose that there was a dropdown control for each mode that listed all modes from which you could select where to get the defaults.
“Get defaults from: [ list of all built-in modes ][v]”
…you could then use that control to tell Rhino from where to get this new mode’s defaults.
That’s all that is happening now, only there is no dropdown, it’s automated. Perhaps adding the dropdown would be a “clearer” approach to this, and would also solve the problem for older modes as well as modes created using “New”. I guess that’s another discussion…but I like the idea… You could then create a “Defaults” display mode, and assign it to whatever mode you want, so that when “Restore defaults” is clicked, its values are used…you could then also determine modes that have no defaults (i.e. clicking the Restore button would do nothing…right now, that’s not possible, but it solves preventing accidentally nuking a mode you’ve spent hours/days tweaking).
I’ve/we’ve somewhat gotten offtrack here, but given all of that… once Rhino knows how to associate a mode with a specific set of defaults… It can now show you visually which settings are different from the defaults…thereby letting you know exactly which settings you’ve actually changed… But again, I don’t really know if users would find that useful.
Anyways, if anything, this discussion has flushed some things out (I’m really liking that dropdown idea more and more)… But for now, I will remove the highlighting for custom modes.
Thanks,
-Jeff
Hi Jeff - I confess I never messed with that in any systematic way until it came up today, but what I expected is nothing would happen… (i.e. that button is really not relevant to non-default modes). A ‘restore defaults’ to a choice of existing modes on the other hand would make perfect sense to me.
Also, I don’t think it’s bad, exactly, that it’s currently restoring the ‘parent’ mode defaults, only that I’ve not found it useful yet and it’s not exactly clear unless you fuss with it, what should happen or why the blues are there.
-Pascal
FWIW, I think it is really useful to be able to see exactly what is non-default in a custom mode.
The problem with the current system, though, is that, unless you name your custom modes “Copy of Default xyz”, you cannot tell which default the custom mode is based on.
So, my vote (but @Trav says he’ll riot when I get to vote) would be to keep the blueification but add an entry that states the “parent mode” under the name. - You will, of course, make that entry into a drop-down, which is fine (as long as picking a different one from that list doesn’t change the settings of the mode).
Note, when you delete a mode from the list, all mode names under Rhino Options > View > Display Modes are painted black, even if they have modifications. Exiting the dialog and entering it again corrects this. I can YT this if you want, @jeff.
1 Like
my 2c : I like the way the “blue” is implemented to indicate the non-default changes.
If there is better way to do it, great, but please don’t take it away completely.
–jarek
1 Like
It’s not being removed completely… It’s still going to work with the built-in display modes…it’s only being turned off for custom display modes.
1 Like
Hi All
My input: Really like @wim’s idea of putting the name of the original mode somewhere, so that you know it came from. Please do keep the highlighting in the custom modes as well - it makes it so much easier to mess around with the settings and keeping track of the changes.
-Jakob
1 Like