On Sun, 29 Jan 2023 17:10:26 GMT, Michael Strauß <mstra...@openjdk.org> wrote:
>> Platform preferences are the preferred UI settings of the operating system.
>> For example, on Windows this includes the color values identified by the
>> `Windows.UI.ViewManagement.UIColorType` enumeration; on macOS this includes
>> the system color values of the `NSColor` class.
>>
>> Exposing these dynamic values to JavaFX applications allows developers to
>> create themes that can integrate seamlessly with the color scheme of the
>> operating system.
>>
>> Platform preferences are exposed as an `ObservableMap` of platform-specific
>> key-value pairs, which means that the preferences available on Windows are
>> different from macOS or Linux. JavaFX provides a small, curated list of
>> preferences that are available on most platforms, and are therefore exposed
>> with a platform-independent API:
>>
>>
>> public interface Preferences extends ObservableMap<String, Object> {
>> // Platform-independent API
>> ReadOnlyObjectProperty<Appearance> appearanceProperty();
>> ReadOnlyObjectProperty<Color> backgroundColorProperty();
>> ReadOnlyObjectProperty<Color> foregroundColorProperty();
>> ReadOnlyObjectProperty<Color> accentColorProperty();
>>
>> // Convenience methods to retrieve platform-specific values from the map
>> Optional<Integer> getInteger(String key);
>> Optional<Double> getDouble(String key);
>> Optional<String> getString(String key);
>> Optional<Boolean> getBoolean(String key);
>> Optional<Color> getColor(String key);
>> }
>>
>>
>> The platform appearance is defined by the new `javafx.stage.Appearance`
>> enumeration:
>>
>>
>> public enum Appearance {
>> LIGHT,
>> DARK
>> }
>>
>>
>> An instance of the `Preferences` interface can be retrieved by calling
>> `Platform.getPreferences()`.
>
> Michael Strauß has updated the pull request incrementally with one additional
> commit since the last revision:
>
> Use Optional for convenience methods in Preferences
In the context of adding theme support in javafx, I think this PR is a step in
the right direction. I also like a small set of platform-independent
properties like fg and bg colors. I wonder if the same approach can be
extended for other aspects of platform L&F, like fonts, spacing, and may be
other aspects (like, hiding scrollbars setting on Mac?)
I agree with @kevinrushforth - we'd need more discussion on the actual
implementation. There are a few items that I feel are unnecessary, or might be
done differently, and I'd like to learn what other people think.
Specifically:
1. Appearance enum seems unnecessary - there might be more choices in a
specific platform (Mac Ventura has three: dark/light/auto). Perhaps using
fg/bg color intensity is sufficient to find out whether the overall theme is
"dark" or "light".
2. ObservableMap. Similarly to Node.getProperties(), I wonder if there might
be a better way to observe the changes. May be a different metaphor
(subscription?), like adding a value change listener to a specific key. We do
need a set of keys (perhaps that can be an ObservableSet). Having said that,
ObservableMap is good enough solution, and forgive me for stating the obvious,
it should not initialize anything if the platform properties have not been
requested by the application code.
What do you think?
-------------
PR: https://git.openjdk.org/jfx/pull/1014
