On Tue, Jan 31, 2023 at 6:14 PM Pedro Duque Vieira <pedro.duquevie...@gmail.com> wrote: > Thinking of existing themes migrating to this StyleTheme API (90% are > implemented as author stylesheets), some visual glitches may start appearing > for users of those themes once they start using the migrated versions (since > they will go from being author stylesheets to user agent stylesheets). > So, 2 things to think about: > 2.1 - How important is it that we think about this use case: existing themes > migrating to this new API. I'd say we should probably think about it when > designing this new API. > 2.2 - The second thing then is, how problematic will it be for programmers > using these themes to have their apps start having visual glitches because of > these themes changing from author stylesheets to user agent style sheets? > Perhaps we simply don't bother with this last point and simply have it be the > price of innovation. And so programmers will have to adapt their applications > and remove any code that is overriding the styles defined in the StyleThemes > (which are likely causing these visual glitches when migrating to Themes > using this new StyleTheme API). The same for any styles already defined in > custom author stylesheets that are being used by the application and that > might be NOW overriding the styles of the theme.
1) Ease of migration should be an important consideration, but there are also other considerations. I'd argue that getting the feature stacking and mental model right is more important, and giving themes a way to individually select if the stylesheets are user-agent or user stylesheets makes it hard to understand why my locally-set property value is being ignored by JavaFX in one theme, but not in the other. 2) The scenario you describe occurs when an application sets the value of styleable properties from code, but the values are overridden by an author stylesheet. Yes, that might happen, and I think it's up to the application developers to fix that. The reason why I think we should only support `Application.userAgentStyleTheme` in the first version of this new feature is quite simple: I'd rather have the feature actually make it into JavaFX than be stuck in review because it's too large and too complex of a change. User-agent style themes are pretty easy to implement (most of the code is already in place), while author style themes are not. We can add author style themes as a follow-up enhancement. > I don't think we should put having StyleTheme be just a collection of > stylesheets and nothing else as a requirement. I'd rather think of StyleTheme > as being the concept of a Theme and all the possible properties and > definitions of what a Theme is. This is one of the strengths of this new > feature you've proposed, i.e. > having the concept of a Theme exist in JavaFX whereas in the past there was > no such concept and a "Theme" was just a collection of stylesheets. Added > through the getStylesheets() method or through the setUserAgentStylesheet > method. > > I'll just note that we don't just want the applications to be light or dark > depending on what is set in the Operating System. You'll also want the > ability to set whether the app is in dark or light mode on a per application > level irrespective of what is defined in the OS (this already happens on many > existing applications out there). So I think that DarkModeAware interface > would have to have a method like: > ThemeMode getMode(); > Where ThemeMode can either be LIGHT, DARK or OS_DEFINED (I've named it > ThemeMode just as an example). > > So I think we could do it in 2 ways: one way would be to do it as you say > (though DarkModeAware interface would need the getMode() method that I > suggested, I think) or add a method in the StyleTheme interface itself in a > future release: > ThemeMode getMode(); > That method would probably need to have a default implementation that simply > returns LIGHT because of retro compatibility. > > So, ThemeMode could be one of 3 possible values: LIGHT, DARK or OS_DEFINED. > Where OS_DEFINED means that the app will honor whatever is defined at the OS > level. > JavaFX Window decorations would need to respect whatever is returned in this > getMode() method and change their decorations to either LIGHT or DARK > depending on its value. This would also remove the need for boilerplate code > that for every Window that is created sets it to be LIGHT or DARK depending > on whether the Theme is LIGHT or DARK. > > Of course, we can also simply support this from the get go and have this > method exist in StyleTheme from the start. I'll point you to this document, which describes the latest version of this feature: https://gist.github.com/mstr2/9f46f92c98d3c86aa6a0b4224a9a6548 What do you think about the interaction between the various parts of the new API, especially in regards to the appearance of native platform decorations? I'm not convinced that it is a good idea to make either `StyleTheme` or `Stage.appearance` more complicated by automatically inferring the value of one from the other.
