Platform preferences API

[Michael Strauß]

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.rushforth at 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.
>