Make themes a first-class concept in JavaFX

[Michael Strauß]

Good point about the STYLESHEET_CASPIAN and STYLESHEET_MODENA values.

Here are a few more aspects for discussion:

Any sufficiently sophisticated theme will probably be comprised of
several stylesheets. In fact, the built-in themes are a good example
for that. Since the current API doesn't allow to specify more than a
single user-agent stylesheet, this is quite limiting and requires some
workarounds, for example by manually adding auxiliary stylesheets to
every Scene.

A thing that is quite common for real-world apps is to keep the
built-in theme, and then manually add stylesheets that change aspects
of the built-in theme. The downside of this is that this creates a
dependency on a particular version of the JavaFX built-in theme. A
more reliable solution would be to fork the built-in theme and create
a custom theme from that. Since the proposed API has a very thin
surface and treats themes simply as dynamic collections of
stylesheets, forking an existing theme requires duplicating the logic
code that might be contained.

In order to keep maintenance cost for the OpenJFX project down,
interpreting platform theme properties is the sole responsibility of
theme developers. This may incur a significant effort, since theme
developers may need to understand the meaning behind various optional
properties of different platforms.

As it stands, platform properties are only reported for Windows
platforms. It will require additional development effort to add
support for this to other Glass backends.

Am Fr., 21. Mai 2021 um 18:08 Uhr schrieb Kevin Rushforth
<kevin.rushforth at oracle.com>:
>
> Please file an Enhancement request first, and from that enhancement
> create a new CSR. Ideally JBS would prevent direct creation of an issue
> with an issuetype of CSR.
>
> As for the feature itself, it seems useful, but will need discussion as
> to the value proposition (i.e., cost / benefit), and then agreement on
> the API itself. One thing that would help in this is some discussion
> around how an application developer would use it.
>
> I have one initial comment on the currently proposed API. You'll likely
> need to rethink your proposed change to the STYLESHEET_CASPIAN and
> STYLESHEET_MODENA constants. It seems attractive to change it for
> consistency, but it is an incompatible change. It is likely there are
> applications or third-party controls that rely on the current values.
> Also, it leaks the name of the internal com.sun.javafx.* package where
> it happens to live today, which is an implementation detail. I think you
> should stick with the existing constants and translate it on use in the
> implementation as needed.
>
> -- Kevin