Where to store Global Settings for Plugin
-
I've been writing the Medeek Truss Plugin for almost 6 months now and I've realized that I need to have some (persistent) global settings that the user can adjust. I'm still undecided on the best way to store this information whether in a text file or in the registry. I would like it to work on either Windows or Apple, hopefully seamless. I've found all sorts of various discussions on the topic but ultimately it has left me more confused as to the appropriate or best way to handle this. Can anyone give me a definitive answer on the best way to store persistent settings for a plugin? I would prefer to store settings in a text file but my concern is platform dependence.
-
In the API documentation there is this:
Sketchup.write_default(section,variable{,optional_default})
Sketchup.read_default(section,variable,value)Is this the preferred method of storing plugin data? Pros and cons of this method versus storing user data in a text file.
-
Sketchup.read/write_default is normally what you'd pick to store extension persistent data. But note it's persistent to the given user and SketchUp version.
If you need persistence across users or SketchUp versions you need to roll your own. Whether you use registry/plist, INI files, JSON files, YAML files is all up to you. I like JSON in the way they are readable and nestable.
For the location of these files you should consult the OS guidelines to where to store them. Windows and OSX both have clear guidelines for this.
-
The Registry/plist based API-methods write/read any user/version specific data for your extension.
But remember that you will need to 'construct' those remembered strings in an acceptable way - for example perhaps use xxx.inspect and eval(nnn) to set/get things like strings, arrays etc...However, since recent SketchUp versions will put your user's Plugins folder in a readily accessible/writable folder, then the extension's ../Plugins/ExtensionName subfolder [or a more likely, a nested subfolder] can contain a file like .txt, .dat etc, containing your stored data in a similar 'extractable' text format.
BUT do NOT use any pre-RBZ-packaged files like rb/htm/html/js/css etc - because these as 'hashed' during the >=v2016 signing process, and therefore changing any of those will break the hash-check as SketchUp starts.
So use another file suffix like txt/dat/ini/wtf etc... -
I wouldn't recommend writing settings in the Plugins folder. Think of the Plugins folder like the Program Files folder on Windows - it's where the application packages are, settings and docs have other dedicated locations.
-
I agree with thomthom [somewhat]... BUT it is a possibility, which wasn't available in earlier version, when Plugins was located within the 'Program Files' folder tree...
BUT the Registry in is not a particularly friendly place...
You can of course make an Extension specific subfolder in some User/Documents or Temp or Local folder path, that then contains your file-of-data...
But thus far SketchUp leaves it up to you...
-
@thomthom said:
I wouldn't recommend writing settings in the Plugins folder. Think of the Plugins folder like the Program Files folder on Windows - it's where the application packages are, settings and docs have other dedicated locations.
Personally, I have always disagreed with this interpretation...
These files are the Plugin/Extensions additional files, without the files the plugin will be less then intended, they 'should' remain together in a single location or be stored in Sketchup.read/write_default...
The two main issues I've previously expounded are:
the accidental removal if stored elsewhere...
orphaning if the plugin is deemed no longer required...The second is my biggest bugbear...
If you desire to locate these 'settings' elsewhere, you should provide an easily accessible 'uninstaller' that removes them whenever the user wants...
If users requirers portability of any settings, this can be handled by an export settings method with a corresponding import settings method...
too many plugins litter, too many files in too many locations...
This should be discouraged not condoned...
john
-
I don't really care that the values are persistent across users or version, in fact I would rather they be unique for each user and for the SU version that way someone could have separate global settings for 2015 and 2016 of SU. All I really care about is that the settings are persistent across sessions.
Given this intended usage it would seem that the Sketchup.read/write_default method would probably work just fine in my case however TIG's comment that the registry is not a friendly place has me second guessing that conclusion.
What specifically are the cons with using the registry method?
-
Both writing and reading with the registry with http://www.sketchup.com/intl/en/developer/docs/ourdoc/sketchup#write_default and http://www.sketchup.com/intl/en/developer/docs/ourdoc/sketchup#read_default is relatively straightforward and is applicable on an individual version and user basis, and can be construed to cover your own extension name and several key/value pairs as desired.
However, the 'friendliness' I alluded to was relating to how it stores some of your data values.
You can easily make some tests without attaching it to your main code.
The newer versions of Sketchup do quite a good job of storing integers, floats, strings***, arrays*** and hashes and reading them back in successfully.
See below for the *** caveats...*** There are some pitfalls to be avoided - e.g. including a double-quote
"inside a string [e.g. even when properly escaped with a\]... so do NOT write"1'6\""as a string, because you cannot read it back [the read back and now 'un-escaped'"produces an error], so you must use"1'6\\\""to ensure that the enclosed"is properly escaped as\"when it's written, so it can be read back successfully...
This sidestep applies to any plain string and also any string stored inside an array [where Ruby also encloses these inside double-quotes], but perversely hashes are OK with this because when a string is inside a hash that's written to the registry it is properly escaped 'doubly' ["1'6\\\"">>"1'6\""] so reads back in OK without any trapping here...These are just annoyances which can be got around...
But watch out for them...
Advertisement