I think this is another step in the right direction. The
Platform.getPreferences() method would then document that the returned
map is an "unmodifiable map" (as defined by the Map interface docs).
-- Kevin
On 6/16/2023 6:36 AM, Michael Strauß wrote:
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.
