Style themes API

Sat Jan 21 16:19:33 UTC 2023

Hi again Michael,

2-

> 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.

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).
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.

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.

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.

3 -

> 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.

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.
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.
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.

4-

> 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();
>         ...
>     }

Yes, I think that would be great.

Thanks again!

On Mon, Jan 16, 2023 at 11:28 PM Michael Strauß <michaelstrau2 at gmail.com>
wrote:

> Hi Pedro,
> see my comments below.
>
>
> On Mon, Jan 16, 2023 at 1:10 PM Pedro Duque Vieira
> <pedro.duquevieira at 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();
>         ...
>     }
>

-- 
Pedro Duque Vieira - https://www.pixelduke.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20230121/d39846be/attachment-0001.htm>