On Tue, 31 Jan 2023 20:18:05 GMT, Michael Strauß <mstra...@openjdk.org> wrote:
> the reason for the Appearance enumeration and the Preferences.appearance > property is to support dark window frames. I think that, by default, the FX frame decorations should pick up the platform theme (dark, light, accent color, etc.). It should be possible to override this behavior somehow - possibly by setting the base/accent color - but using an enum for this purpose feels unnecessary. > Saving the allocation of just a single map with 20-or-so key-value pairs is > not a convincing reason to complicate the implementation It's not just allocation, but also listening to changes at run time. For example, the user changing the theme from light to dark should, in my opinion, update any running FX application, unless otherwise is prescribed by the application requirements. -andy From: mstr2 ***@***.***> Date: Tuesday, January 31, 2023 at 12:18 To: openjdk/jfx ***@***.***> Cc: Andy Goryachev ***@***.***>, Comment ***@***.***> Subject: [External] : Re: [openjdk/jfx] 8301302: Platform preferences API (PR #1014) 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?) That could indeed be a useful enhancement. 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". While dark/light mode can indeed be detected just by comparing foreground and background color, the reason for the Appearance enumeration and the Preferences.appearance property is to support dark window frames. In this gist<https://urldefense.com/v3/__https:/gist.github.com/mstr2/9f46f92c98d3c86aa6a0b4224a9a6548__;!!ACWV5N9M2RV99hQ!IMBktwM52wz3rGVNfcYTrwhd0QKoYAK2MpRFZkhslCqpdNN8ca8ilF8yLnMfQBywAFpIZ-OirPQAk0US0ltRtKf2sbTJfA$> (see "Stage appearance"), I've described how the stage appearance and platform appearance APIs interact. 1. 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. The use of ObservableMap is debatable. I think that always initializing platform properties makes it easier to reason about the code. Saving the allocation of just a single map with 20-or-so key-value pairs is not a convincing reason to complicate the implementation, especially since most of the platform preferences implementation lives in the Glass toolkit, and not in the user-facing framework. — Reply to this email directly, view it on GitHub<https://urldefense.com/v3/__https:/github.com/openjdk/jfx/pull/1014*issuecomment-1411006332__;Iw!!ACWV5N9M2RV99hQ!IMBktwM52wz3rGVNfcYTrwhd0QKoYAK2MpRFZkhslCqpdNN8ca8ilF8yLnMfQBywAFpIZ-OirPQAk0US0ltRtKeGSZTOsg$>, or unsubscribe<https://urldefense.com/v3/__https:/github.com/notifications/unsubscribe-auth/AZQ34ZHDAK2M2JVQWMHVXNDWVFXQPANCNFSM6AAAAAAUJ6L3R4__;!!ACWV5N9M2RV99hQ!IMBktwM52wz3rGVNfcYTrwhd0QKoYAK2MpRFZkhslCqpdNN8ca8ilF8yLnMfQBywAFpIZ-OirPQAk0US0ltRtKf_uwcosw$>. You are receiving this because you commented.Message ID: ***@***.***> ------------- PR: https://git.openjdk.org/jfx/pull/1014
