Make themes a first-class concept in JavaFX

Michael Strauß michaelstrau2 at gmail.com
Mon May 24 22:48:13 UTC 2021


I can understand that parsing string values feels like a very
lackluster API. But let me offer a counterpoint:

If we provided a set of APIs that exposed particular OS concepts
(light/dark mode, accent coloring, etc.), we would commit ourselves to
supporting these APIs for new versions of all kinds of operating
systems. We'd also need additional APIs to expose whether or not the
particular concept is even available on the current OS. I think
developers would then also expect us to keep track of the changing
trends of OS design and keep offering up-to-date APIs for new features
and design trends. That's a significant cost, considering that JavaFX
currently doesn't even offer a theme that would need all these APIs
(except for high contrast).

On the other hand, assuming the proposed minimal `Theme` API, it would
be pretty straightforward for a third-party library to implement
`Theme` adapters that offer all of the first-class APIs that you
discussed.

As to you other point: in order to be able to extend the build-in
themes, their theme implementations would need to be public API. In
general I think that's okay, provided that the inner workings of the
default themes remain a "black box".



Am Mo., 24. Mai 2021 um 17:48 Uhr schrieb Pedro Duque Vieira
<pedro.duquevieira at gmail.com>:
>
> Hi,
>
> I've been developing JMetro: https://pixelduke.com/java-javafx-theme-jmetro/
> , it's a javafx I've been developing since 2013 when I have some free spare
> time.
>
> I thought I'd chime in since this has been an interest of mine for quite
> some time.
>
> A few issues I experience with the current JavaFX API:
>
> 1 - Like Michael said here, the current way all themes are usually
> developed is to extend the default JavaFX theme (currently modena). This
> has a few problems:
> 1.1 - If you want it to be a user agent stylesheet you have to copy
> everything from the default theme into your theme
> 1.2 - If you're NOT going to go for it being an user agent stylesheet, you
> simply add your theme "on top" of the default user agent stylesheet (e.g.
> Modena) but this has a problem because now the rules of your theme will
> have precedence over rules set through code (e.g. style rules in FXML,
> style rules in code).. which can be unexpected from a user using the theme.
>
> 2 - There's no built-in support for new theme features existing in most
> Operating Systems nowadays like: dark/light style, chosen accent color...
>
> ---
>
> I think adding an API to solve this is a good idea.
> As a first comment and focusing only on the stuff I would change, I don't
> particularly like the "void platformThemeChanged(Map<String, String>
> properties);"
> Namely the fact that we're using strings to identify properties like
> whether we use dark or light style, etc. I would prefer as a developer to
> not have to match strings, etc (which can be a problem if you misspell a
> string and you'll only notice these problems during runtime).
> I would like for there to be an API for the user to say whether he wants
> the dark or light style, also for whether light or dark style is selected
> in the OS itself. I would also like to have an API for selecting the accent
> color and to know which accent color is set in the OS.
> Potentially we could have javafx properties for each one of these, at least
> for whether we want light or dark style and which accent color we're using.
>
> I would also like for there to be some API where one could say whether the
> theme is supposed to be a user agent stylesheet or not. Allowing one to
> build on top of the default theme stylesheet (Modena) without copying the
> default theme definitions but still being able to say that you want your
> custom theme to be a user agent stylesheet.
>
> I don't have much time right now to comment further on the API or give
> precise suggestions (I'll probably have more time next week) but here's my
> 2 cents.
>
> Thanks,
>
>
>
> --
> Pedro Duque Vieira - https://www.pixelduke.com


More information about the openjfx-dev mailing list