Hi Pedro,
see my comments below.
On Mon, Jan 16, 2023 at 1:10 PM Pedro Duque Vieira
<pedro.duquevie...@gmail.com> wrote:
>
> No problem, I mentioned those in my first comment but probably got lost in
> this conversation.
> 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.
>
> 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).
> This is already possible by choosing to add your stylesheets to the Scene
> getStylesheets() method or by using the setUserAgentStylesheet() method.
Currently, the order of precedence is as follows (from highest to lowest):
1. Node.style
2. Parent.stylesheets
3. Scene.stylesheets
4. StyleableProperty values set from code
5. Application.styleTheme
6. Application.userAgentStylesheet
I understand you're suggesting that a style theme could effectively be
inserted between 3 and 4, such that it overrides local values set from
code, but not values set in Scene stylesheets.
I'm not sure that the added complexity is worth the marginal benefits.
As far as JavaFX has always had the concept of built-in "themes",
users could reliably override any StyleableProperty value from code.
Developers might be surprised to find out that they can't set the
value of a StyleableProperty from code because an application-wide
style theme overrides any local changes.
The migration story from Scene stylesheets to a StyleTheme might be a
little bit easier, but it complicates the mental model of how themes
interact with the CSS cascade.
> 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.
> 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.
> 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.
> 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).
I agree that it would be nice to have a way to programmatically
control the appearance of system-provided window decorations.
It's not entirely related to style themes: a style theme is an
application-wide concept, while window decorations are specific to
each individual window.
Maybe we could do this similarly to the Stage.initStyle method, which
serves a similar purpose of setting up window decorations.
> 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".
If we wanted to expose this front-and-center, we could add these
properties to the Platform.Properties interface:
public interface Preferences extends ObservableMap<String, Object> {
ReadOnlyBooleanProperty darkModeProperty();
ReadOnlyObjectProperty<Color> accentColorProperty();
...
}
