I've been assessing my need and use of preferences data in various plugins.
I see that AOI is now using at least 2 different preferences systems:
1. one or more files in the .artofillusion folder (findable using ApplicationPreferences.getPreferencesDirectory())
2. The Java java.util.prefs.Preferences class.
Having read the documentation on the java.util.prefs.Preferences class, it *seems* quite nice. In addition, Peter is now using it in parts of the core AOI code.
So, does anyone have any useful recommendations on handling preferences in plugins?
Note: I had hoped that the new plugin infrastructure would provide centralised support for plugin preferences. If we agree on a viable preferences solution, I will probably code it up into a centralised service so that other plugin developers aren't constantly reinventing the wheel.
Personally all i would want is some "getPrefsObject" type method somewhere that is really nothing more that a hash map with key value strings. This would be more than good enough for the Fluids plugin. The saving/loading and location of the file could then be left to AoI
At one point, I wanted to completely switch over to the Java Preferences API, but people protested that they really liked having a file they could easily copy from one computer to another. So now I use files in the .artofillusion directory for things you might want to transfer between computers (basically, everything you set in the Preferences window), and the Preferences API for things where that wouldn't be appropriate (like the list of recently accessed files).
Thanks for the clarification - I was wondering why Occam's right-hand man had multiple systems going :o)
So it seems to me we have 4 options for plugins preferences:
1. Standardise on the Java preferences API and provide an export/import facility
2. Standardise on a single file in the .artofillusion directory
3. Standardise on one file per plugin in the .artofillusion folder
4. Standardise on one or more files per plugin in the .artofillusion folder
I'll start on the public API, and we can tinker with the implementation behind that if need be.
All thoughts and suggestions welcome.
Log in to post a comment.
Sign up for the SourceForge newsletter:
You seem to have CSS turned off.
Please don't fill out this field.