RFR: 8301302: Platform preferences API [v3]

[Michael Strauß]

On Mon, 24 Apr 2023 07:14:47 GMT, John Hendrikx <jhendrikx at openjdk.org> wrote:

> That's not quite what I meant. You can add listeners still and get instant change notifications. Just like when I listen to the `backgroundProperty` of a control, and someone changes it, I get notified instantly and the change is reflected (in the property) instantly. Only when the next pulse fires is the change actually rendered.
> 
> I would think the same is possible with say the appearance property. When I change it from LIGHT to DARK, everyone interested gets this notification immediately. On the next pulse, the change is noticed and only then do we change the stylesheets or make other adjustments that are high impact. Basically, the computationally expensive stuff happens during a pulse; it could register invalidation listeners on properties of interest which just set a flag, that is checked and reset on the next pulse.
> 
> I'm not 100% sure, but it seems you want to add listeners to these properties yourself to instantly trigger the Theme updating code -- I'm saying, only set a boolean that they've changed, check it on the next pulse using `Scene#addPreLayoutPulseListener` (or perhaps there is another mechanism you can tap into internally), and then trigger the Theme change.

In the case of themes, listening to a changing preference may _be_ the expensive stuff, since it can involve recreating the entire list of stylesheets programmatically. Currently, a theme implementation might do something like this:


public class MyTheme implements StyleTheme {
    private final InvalidationListener preferencesChanged = observable -> {
        // change getStylesheet() list
    };

    public MyTheme() {
        Platform.getPreferences().addListener(new WeakInvalidationListener(preferencesChanged));
    }

    ...
}


However, I'm thinking that the Preferences API might not be the right place to solve this problem. Maybe that should be built into the style theme API instead, for example with another interface:


public interface PlatformStyleTheme extends StyleTheme {
    void onPreferencesChanged(Iterable<MapChangeListener.Change<String, Object>> changes);
}


The Preferences _implementation_ would then aggregate the changes that have accumulated since the last pulse, and inform the current style theme by invoking its `onPreferencesChanged` method. This means that a style theme doesn't need to register listeners for different kinds of preferences, and the Preferences API can behave just as any normal property would behave.

-------------

PR Comment: https://git.openjdk.org/jfx/pull/1014#issuecomment-1520681831