I don’t know the context of this discussion but I’d like to add that whenever you change ROs in your custom tool, make sure to remember the original values and reset them when the tool is deactivated. Otherwise users will struggle knowing why their model suddenly appears different.
This is a related topic thread. The “continued from link” is at the top of the thread, was regarding changing active context within a tool. It really didn’t have much to do with the stated subject of that thread so I broke it out into it’s own. (So searchers might find it more easily.)
Agreed. This is why, in my examples above I store the previous setting, and provided restore methods along with getter, setter and toggles.
Although I did not treat the faders they can be done in a similar way. But their toggles might toggle between no fade and the previous setting ?
I did TRY to remember. But when I looked at rendering options I didn’t see them because I was looking for something related to “components” and didn’t see it. This is an area of the API where the organization and terminology used is sometimes very different from the SU UI. It would be helpful at least if the statement “The majority of the rendering information returned exists in the Styles dialog” was amplified to refer to the exceptions.
Firstly, most of us here can agree that the RenderingOptions hash keys are a bit too “concise” in may cases.
It makes us wonder why they were named the way they are. The obvious answer is similar to the answers I gave you in your thread attacking the name of Attribute Dictionary.
It most likely has to do with the names of objects on the C-side of the SketchUp code. When the original API coder(s) implemented (aka exposed) the rendering options to the Ruby subprocess, they most likely just used the same internal key names they use on the C-side, so that there need be no lookup table or humongous Cswitch statement.
These internal C side key names make (or made) sense to the SketchUp core programmers.
In many places the UI terminology (labels) changed over the years and the documentation did not.
I would agree with this.
ALSO, it would help if the RenderingOptions API doc had a multi-column key table.
Key on the left, the GUI name, the GUI dialog (referring to Model Info and panel or Styles Manager and panel), and an informational column for those options that have multiple numeric value settings such as RenderMode.
My original post stated that I didn’t see any way to do this, which is a valid statement of fact.
I’m well aware of the historical reasons for the various terminological confusions, but we agree that the API documentation should make a few more attempts to point them out. Then newbies wouldn’t have to wade through these forums in the first place.
Many of the terminological confusions are simple enough: where the UI says “car” the API says “automobile”.
But some (like “attribute dictionary”) are much more egregious, like “car” vs “rocketship”…