Handling updates to the JavaFX Caspian look

Jeff McDonald deep.blue.6802 at gmail.com
Wed Mar 14 02:46:40 PDT 2012


This is really two questions (1) Should you add this API (2) If so, when. I
vote that it be added. Secondly, the sooner you add it, the better. The
sooner it's added the fewer developers the change will affect simply
because as time goes on more developers will begin to use JavaFX for their
projects.

I'd still like to be able to set the stylesheet for my entire app (not just
a scene at a time or the JVM as this proposal would enable). Hmmm ...
that's another good candidate idea for the App kernel. (I believe there's
already a feature request for that).

Adding the API doesn't keep you from getting into the same situation as
Swing. One reason that Swing apps were stuck with the Metal L&F was that
developers created UIs that were dependent on the exact pixel sizes of
components and text for testing, alignment, and all sorts of things. You'll
have the same challenge with changing the JavaFX default L&F as Swing did
in that sense. The real gain being made is that there will be an API in
place that allows the UI to be updated as the state of UI design changes
over time, and allows developers to pick a "default" theme that won't break
fragile apps. Keeping the old UIs may also add some maintenance overhead in
the sense that as new components are added after a new default theme has
been enable then the old themes will also need to be updated as well to
support any new components.

The ability to evolve the L&F over time will be important to the long term
success and usefulness of JavaFX, and having an API to change the default
theme is a step in the right direction.

Cheers,
Jeff

On Tue, Mar 13, 2012 at 5:47 PM, Jonathan Giles
<jonathan.giles at oracle.com>wrote:

> Hi all,
>
> Today I came across the RT-19713 [1] Jira issue I filed against myself
> recently. This Jira issue basically states that we should have API in
> JavaFX that allows for developers to lock down and specify a particular
> default stylesheet, and if this isn't specified by the developer, they will
> be automatically updated in future releases if we ever consider changing
> the default style sheet. We would always ship earlier style sheets as well,
> so if the preference was set, the style sheet would be there in the jar
> file.
>
> The reason why I want this feature is that I've seen tweaked caspian style
> sheets (for example the one used in the upcoming Scene Builder tool) that I
> would one day love to be the default style sheet for JavaFX as it (in my
> opinion) is more refined. Similarly, I don't think anyone wants to end up
> in the same situation as Swing, where the default L&F is Metal, because
> moving the default to a more modern L&F would potentially break (or at
> least maim) many deployed Swing applications.
>
> Ideally we would have had API like this from the get-go, but alas, it did
> not happen. Adding API now that by default auto-updates people is of course
> breaking a contract we have with developers, but I feel that it is better
> to break this contract now than to forever wish that we could provide a new
> style sheet and never be able to do it. I think the main thing is to
> communicate this change as loudly and from as many roof tops as possible.
> Perhaps there are others on this list that disagree and have different
> opinions. Feel free to share them.
>
> Finally, as of now, there is no intention to ship an updated style sheet
> that would replace the default, but I'm looking ahead to future releases
> where this may be desired. Perhaps JavaFX 3.0 may include a visual refresh,
> for example. If anyone has any thoughts on this proposal, please reply on
> this thread (and preferably also leave a comment on the Jira issue). I
> don't have any proposed API for this issue, but if anyone has any thoughts
> on this, please feel free to share them also.
>
> [1] http://javafx-jira.kenai.com/**browse/RT-19713<http://javafx-jira.kenai.com/browse/RT-19713>
>
> Thanks,
> Jonathan
>


More information about the openjfx-dev mailing list