I think we should wait and don't do this in the short term. Many recent apps don't care for platform appearance at all.
Take Microsoft windows for an example, there are many layers of "evolution" and they all look different on the same OS. Linux will be a nightmare, you have many desktop environments, and if you only consider gnome, it's all CSS based and you can't just obtain a color (because it's on the css). Recent Ubuntu have accent colors, but that's if you use the Yaru theme. If in the future apps start to look the same again we should consider it. The tendency right now seems to be "apps don't have to look the same". Behavior should be consistent, style probably don't. -- Thiago Em qua., 14 de jun. de 2023 15:47, Kevin Rushforth < kevin.rushfo...@oracle.com> escreveu: > 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 > >
