<div dir="ltr">Hi again Michael,<br><br>2- <br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Currently, the order of precedence is as follows (from highest to lowest):<br>1. Node.style<br>2. Parent.stylesheets<br>3. Scene.stylesheets<br>4. StyleableProperty values set from code<br>5. Application.styleTheme<br>6. Application.userAgentStylesheet</blockquote><br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">I understand you're suggesting that a style theme could effectively be<br>inserted between 3 and 4, such that it overrides local values set from<br>code, but not values set in Scene stylesheets.<br>I'm not sure that the added complexity is worth the marginal benefits.<br>As far as JavaFX has always had the concept of built-in "themes",<br>users could reliably override any StyleableProperty value from code.<br>Developers might be surprised to find out that they can't set the<br>value of a StyleableProperty from code because an application-wide<br>style theme overrides any local changes.<br>The migration story from Scene stylesheets to a StyleTheme might be a<br>little bit easier, but it complicates the mental model of how themes<br>interact with the CSS cascade.</blockquote><div><br></div><div>I've been building javafx themes for years now. Started creating JMetro in JavaFX version 2. During this time I've been following how other themes are being built and I can say that about 90% of the themes (rough estimate) that are out there, are composed of author stylesheets, i.e they override values set from code (including JMetro).</div><div>I agree that themes that are to be provided to other developers would probably be better off if they are user agent stylesheets. My point is that migrating those 90% of themes to use this API would be easier if this flag exists otherwise migration would likely introduce UI regressions for developers using those themes.<br><br>To be clear, what I'm proposing is a flag, or enum, or whatever, in StyleTheme that defines whether the stylesheets in the StyleTheme should be a user agent stylesheet or author stylesheet.<br><br>Another point is in making themes that are only to be used locally in a specific app that the developer is creating. It might be of interest that he can toggle this flag and make all settings defined in the theme override any styling set from code (or in FXML) so that he can have a centralized point where all styling is done.<br></div><div><br></div><div><br>3 - </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">I agree that it would be nice to have a way to programmatically<br>control the appearance of system-provided window decorations.<br>It's not entirely related to <span class="gmail-il">style</span> <span class="gmail-il">themes</span>: a <span class="gmail-il">style</span> <span class="gmail-il">theme</span> is an<br>application-wide concept, while window decorations are specific to<br>each individual window.<br>Maybe we could do this similarly to the Stage.initStyle method, which<br>serves a similar purpose of setting up window decorations.</blockquote><div><br></div><div>Style themes are generally either defined as dark or light. i.e. you'll very rarely have a theme that has some Windows with dark decorations and others with light decorations. So I think it makes sense to have this as a theme property.</div><div>The ability to toggle decorations (light or dark) on an individual Window is a good point you're making. Perhaps we should have a global definition in the StyleTheme (whether the theme is light or dark) and a definition that can be set per Window. <br>If you set it on the StyleTheme then all Windows will respect it, but you can override that value on each Window. If you override it on a specific Window, that definition would take precedence over the global StyleTheme one.<br><br>4- </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">If we wanted to expose this front-and-center, we could add these</blockquote><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">properties to the Platform.Properties interface:</blockquote><br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"> public interface Preferences extends ObservableMap<String, Object> {<br> ReadOnlyBooleanProperty darkModeProperty();<br> ReadOnlyObjectProperty<Color> accentColorProperty();<br> ...<br> }</blockquote><div><br>Yes, I think that would be great.<br><br>Thanks again!<br> </div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Jan 16, 2023 at 11:28 PM 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">Hi Pedro,<br>
see my comments below.<br>
<br>
<br>
On Mon, Jan 16, 2023 at 1:10 PM Pedro Duque Vieira<br>
<<a href="mailto:pedro.duquevieira@gmail.com" target="_blank">pedro.duquevieira@gmail.com</a>> wrote:<br>
><br>
> No problem, I mentioned those in my first comment but probably got lost in this conversation.<br>
> 2 – I think the ability to specify in the StyleTheme whether it is a user agent stylesheet, or an author stylesheet could be of interest. Most of the themes I know are composed of author stylesheets (they use the getStylesheets() API in Scene) so migration to using the StyleTheme API would be easier if one could specify this. Conversely specifying that the StyleTheme is a user agent stylesheet will also be very useful in the cases where we’re creating a theme but don’t want it to override styles specified through code, etc.<br>
><br>
> I'll now also add that you might want to create a theme, from the get go, that doesn't get trumped by any rule set through code, either code itself on in FXML files (which will be code anyway). So that the theme css is what always drives the presentation of your app (it has priority).<br>
> This is already possible by choosing to add your stylesheets to the Scene getStylesheets() method or by using the setUserAgentStylesheet() method.<br>
<br>
Currently, the order of precedence is as follows (from highest to lowest):<br>
1. Node.style<br>
2. Parent.stylesheets<br>
3. Scene.stylesheets<br>
4. StyleableProperty values set from code<br>
5. Application.styleTheme<br>
6. Application.userAgentStylesheet<br>
<br>
I understand you're suggesting that a style theme could effectively be<br>
inserted between 3 and 4, such that it overrides local values set from<br>
code, but not values set in Scene stylesheets.<br>
I'm not sure that the added complexity is worth the marginal benefits.<br>
As far as JavaFX has always had the concept of built-in "themes",<br>
users could reliably override any StyleableProperty value from code.<br>
Developers might be surprised to find out that they can't set the<br>
value of a StyleableProperty from code because an application-wide<br>
style theme overrides any local changes.<br>
The migration story from Scene stylesheets to a StyleTheme might be a<br>
little bit easier, but it complicates the mental model of how themes<br>
interact with the CSS cascade.<br>
<br>
<br>
<br>
> Ok thanks for clarifying what happens on Mac. Yes on the Windows OS, JavaFX won't honor your system wide settings. If your system is in dark mode the frames will still be shown in light mode.<br>
> But anyways, I think, the programmer should be able to toggle the dark/light mode setting irrespective of what is defined in the system. There are many apps where you, as a user, can choose dark or light mode in the app itself and it will honor it regardless of what you have defined in the system (e.g. Intellij, Slack, etc, etc). Some will allow you to set whether you want to use the system setting for light/dark mode or your own setting in the app.<br>
> This can be of value in cases where you, as a user, prefer to use an app in dark mode and others in some other mode, so you can choose themes on an app by app basis.<br>
> Or perhaps the developer wants to design an app that's just dark. In that case you'd want the ability to toggle the frame decorations to being dark (all the time).<br>
<br>
I agree that it would be nice to have a way to programmatically<br>
control the appearance of system-provided window decorations.<br>
It's not entirely related to style themes: a style theme is an<br>
application-wide concept, while window decorations are specific to<br>
each individual window.<br>
Maybe we could do this similarly to the Stage.initStyle method, which<br>
serves a similar purpose of setting up window decorations.<br>
<br>
<br>
<br>
> Just to be clear I was just talking about how we would present this API (platform preferences). This property would be a way to more easily know if the system is in dark/light mode, the accent color, without needing to know the specific "key".<br>
<br>
If we wanted to expose this front-and-center, we could add these<br>
properties to the Platform.Properties interface:<br>
<br>
public interface Preferences extends ObservableMap<String, Object> {<br>
ReadOnlyBooleanProperty darkModeProperty();<br>
ReadOnlyObjectProperty<Color> accentColorProperty();<br>
...<br>
}<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>