<div dir="ltr"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">1) Ease of migration should be an important consideration, but there<br>are also other considerations. I'd argue that getting the feature<br>stacking and mental model right is more important, and giving themes a<br>way to individually select if the stylesheets are user-agent or user<br>stylesheets makes it hard to understand why my locally-set property<br>value is being ignored by JavaFX in one theme, but not in the other.</blockquote><br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">2) The scenario you describe occurs when an application sets the value<br>of styleable properties from code, but the values are overridden by an<br>author stylesheet. Yes, that might happen, and I think it's up to the<br>application developers to fix that. The reason why I think we should<br>only support `Application.userAgentStyleTheme` in the first version of<br>this new feature is quite simple: I'd rather have the feature actually<br>make it into JavaFX than be stuck in review because it's too large and<br>too complex of a change. User-agent style themes are pretty easy to<br>implement (most of the code is already in place), while author style<br>themes are not. We can add author style themes as a follow-up<br>enhancement.</blockquote><div><br>Author stylesheets are an inherent feature of JavaFX. It's already a feature that exists so I think developers shouldn't be surprised if author stylesheets override their styles set in code.<br>But anyways, you've convinced me on making this just be a user agent stylesheet for now. Like you say, that way this feature doesn't get too large and we're able to ship it quicker. :-)<br><br><br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"> I'll point you to this document, which describes the latest version of<br>this feature: <a href="https://gist.github.com/mstr2/9f46f92c98d3c86aa6a0b4224a9a6548" rel="noreferrer" target="_blank">https://gist.github.com/mstr2/9f46f92c98d3c86aa6a0b4224a9a6548<br></a>What do you think about the interaction between the various parts of<br>the new API, especially in regards to the appearance of native<br>platform decorations?<br>I'm not convinced that it is a good idea to make either `StyleTheme`<br>or `Stage.appearance` more complicated by automatically inferring the<br>value of one from the other.</blockquote><div><br></div><div>The fact that a theme is either dark or light is strongly correlated to whether you as a developer want all window decorations to be light or dark. I'd say that very few use cases will want to have some windows to be light and others to be dark.</div></div><div>As such, this API as it is, will force developers to set the window decorations to either light or dark every time they spawn a new Window (spawning a separate Window, a Dialog, etc). I'd say it would be a good idea to set the window decorations based on what is defined in the StyleTheme with the possibility to override them if you set it on the Window itself.<br><br>Looking at the doc you created. Some comments:</div><div>- I like the Preferences API<br>- "Appearance" or "ThemeAppearance"? "Appearance" sounds like a rather generic term that could mean anything..<br>- perhaps rename the Stage appearance property to something like: "frameDecorations", e.g. "setFrameDecorations(Appearance)"?<br>- " A future enhancement may refactor the built-in themes to make color definitions swappable". This is already possible. Modena has its color definitions given by css variables which can be easily overridden in CSS. That's also a strong part of how I currently switch JMetro to either dark or light version without having to duplicate every style definition. Side note: JMetro is composed of several stylesheets (more than 1) so it would be a nightmare or impossible to make JMetro be a user agent stylesheet with the current state of the JavaFX API (+1 for this new API :-) ).<br>- Perhaps rename "Application.userAgentStylesheetXX" to  "Application.styleThemeXX" and keep the semantics? If we make it be "userAgentStylesheetXX" it means we can no longer in a future version make StyleTheme have a property to define whether they are to be user agent stylesheets or author stylesheets. It gives less room for us to be able to change our minds in the future.<br>- Perhaps instead of the section "Goals" being named "Goals" we could name it "Advantages of this API" or something along those lines and have it be the first topic. I think the first question people will ask is: "what's the advantage of this new feature?".. so I think it would be nice if it's the first topic so that we grab people's attention from the start.<br>- instead of "Promote CSS user-agent themes from an implementation detail to a first-class concept.", perhaps something more clear? Something like: "Allow easier creation of themes that are composed of user agent stylesheets (like Modena and Caspian). These themes may be composed of more than 1 user agent stylesheet which isn't possible with the current javafx API". Also perhaps make reference to the fact that 90% (rough estimate) of themes out there are composed of author style sheets and it's difficult for them to be different, which can be problematic for users of those themes: styles set in code will be overridden, styles set in FXML, styles set in author stylesheets created by the developers if the specificity of those styles is lower than the themes styles.. <br></div><div><br></div><div><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Feb 1, 2023 at 12:22 AM Michael Strauß <<a href="mailto:michaelstrau2@gmail.com">michaelstrau2@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On Tue, Jan 31, 2023 at 6:14 PM Pedro Duque Vieira<br>
<<a href="mailto:pedro.duquevieira@gmail.com" target="_blank">pedro.duquevieira@gmail.com</a>> wrote:<br>
> 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).<br>
> So, 2 things to think about:<br>
> 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.<br>
> 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?<br>
> 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.<br>
<br>
1) Ease of migration should be an important consideration, but there<br>
are also other considerations. I'd argue that getting the feature<br>
stacking and mental model right is more important, and giving themes a<br>
way to individually select if the stylesheets are user-agent or user<br>
stylesheets makes it hard to understand why my locally-set property<br>
value is being ignored by JavaFX in one theme, but not in the other.<br>
<br>
2) The scenario you describe occurs when an application sets the value<br>
of styleable properties from code, but the values are overridden by an<br>
author stylesheet. Yes, that might happen, and I think it's up to the<br>
application developers to fix that. The reason why I think we should<br>
only support `Application.userAgentStyleTheme` in the first version of<br>
this new feature is quite simple: I'd rather have the feature actually<br>
make it into JavaFX than be stuck in review because it's too large and<br>
too complex of a change. User-agent style themes are pretty easy to<br>
implement (most of the code is already in place), while author style<br>
themes are not. We can add author style themes as a follow-up<br>
enhancement.<br>
<br>
<br>
<br>
> 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.<br>
> 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.<br>
><br>
> 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:<br>
>   ThemeMode getMode();<br>
> Where ThemeMode can either be LIGHT, DARK or OS_DEFINED (I've named it ThemeMode just as an example).<br>
><br>
> 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:<br>
>   ThemeMode getMode();<br>
> That method would probably need to have a default implementation that simply returns LIGHT because of retro compatibility.<br>
><br>
> 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.<br>
> 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.<br>
><br>
> Of course, we can also simply support this from the get go and have this method exist in StyleTheme from the start.<br>
<br>
I'll point you to this document, which describes the latest version of<br>
this feature: <a href="https://gist.github.com/mstr2/9f46f92c98d3c86aa6a0b4224a9a6548" rel="noreferrer" target="_blank">https://gist.github.com/mstr2/9f46f92c98d3c86aa6a0b4224a9a6548</a><br>
What do you think about the interaction between the various parts of<br>
the new API, especially in regards to the appearance of native<br>
platform decorations?<br>
I'm not convinced that it is a good idea to make either `StyleTheme`<br>
or `Stage.appearance` more complicated by automatically inferring the<br>
value of one from the other.<br>
</blockquote></div><br clear="all"><div><br></div>-- <br><div dir="ltr" class="gmail_signature"><div dir="ltr"><div>Pedro Duque Vieira - <a href="https://www.pixelduke.com" target="_blank">https://www.pixelduke.com</a></div></div></div>