On Mon, 24 Apr 2023 07:14:47 GMT, John Hendrikx <jhendr...@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
