Platform preferences API

[Andy Goryachev]

my two drachmas (in addition to the comments in the PR and elsewhere):

#3 I think this API should be unidirectional, i.e. limited to reporting the platform preferences and their runtime changes to the application (the key set is immutable, and values cannot be put by the application).  Whenever the applications requires changing of some values by the user/app, the app can create a separate property.

#4 I am ok with Appearance enum as long as it's one of the attributes and is present on every supported platform.

#5 in my case (programmatic generation of a stylesheet on top of standard modena.css), it can be used to generate derived colors as well as proper effects and highlights.

In addition to the questions Kevin asked, I'd like to as

6) Is high contrast mode encoded as another attribute, or does it need two more values in Appearance (high contrast light, high contrast dark)?

7) Is there a way to provide a type-safe interface for retrieving the values from the preferences map?  Alternatively, there should be a table for each platform enumerating keys, value types, nullability, and, ideally, a description.

Thank you,
-andy

From: openjfx-dev <openjfx-dev-retn at openjdk.org> on behalf of Kevin Rushforth <kevin.rushforth at oracle.com>
Date: Wednesday, June 14, 2023 at 11:48
To: openjfx-dev <openjfx-dev at openjdk.org>
Subject: Platform preferences API
I'm finally catching up on the platform preferences API discussion, most
of which is in Draft PR #1014 [1]. The information captured here [2]
provides a good summary of the API.

A PR isn't really the best place to discuss the question of whether this
feature is useful and whether the API is heading in the direction we
want, so I wanted to have a high level discussion of that here.

First of all, I do see the value in having some way to provide the
platform-specific properties like colors, etc, to the user. I'm less
sure that the same class should also allow overriding those properties,
but I can see the value of providing *some* way for the application to
override them.

In order to move this forward, we need to answer the following questions:

1. Is this functionality something we want in the core of JavaFX? I
think the answer is "yes", and it seems like others agree.

2. What is the best way to expose this capability? Currently it is
proposed as an interface that extends ObservableMap (meaning that it
*is* a Map rather than *contains* a map or has some other map-like
representation). This seems fine to me, based on the discussion in the PR.

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.

4. Is an Appearance enum the best way to provide the indication of LIGHT
vs DARK? Do we need it as part of the Preferences API or should it wait
until one of the later RFEs?

5. How do you anticipate this be used by an application prior to having
CSS themes?

-- Kevin

[1] https://github.com/openjdk/jfx/pull/1014

[2]
https://gist.github.com/mstr2/9f46f92c98d3c86aa6a0b4224a9a6548#platform-preferences
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20230615/aacd3082/attachment-0001.htm>