It might indeed be useful to split read-only platform preferences from mutable application preferences. I've updated the API doc [1]; here is the summary: 1. Have `Platform.getPreferences()` return the same interface as before, minus the mutation methods. 2. Have `Application.getPreferences()` return an extension of the `Platform.Preferences` interface, which includes the mutation methods.
The map returned by `Platform.getPreferences()` will only include the preferences that are reported by the platform, while the map returned by `Application.getPreferences()` will also include potentially overridden values. Both maps are updated dynamically when an OS setting is changed, except for overridden values in the `Application.Preferences` map, which will take precedence. [1] https://gist.github.com/mstr2/9f46f92c98d3c86aa6a0b4224a9a6548#platform-preferences On Wed, Jun 14, 2023 at 8:48 PM Kevin Rushforth <kevin.rushfo...@oracle.com> wrote: > > 3. Should the platform preferences API provide the ability to set the > properties (to override them) or should that capability be provided some > other way (e.g., by some other class)? Perhaps this belongs as part of > an eventual theming API, possibly via a "user preferences" class that > extends or wraps the platform preferences class? At least the currently > proposed API moved away from the odd "override" semantics and uses the > standard "put" semantics. That, coupled with the two "reset" methods is > a reasonable API, but I'm still not convinced that the core platform > preferences class is the place for it. Please consider whether having a > separate user / theme preferences interface / class, in addition to the > (read-only) system preferences, might be better. >
