Handling updates to the JavaFX Caspian look

[Jonathan Giles]

Tom,

Thanks for your feedback. I will therefore not modify the ServiceLoader 
code to be more OSGi friendly, and will instead direct people to 
e(fx)clipse and / or the Themes API to manually register their themes.

The API on Application was originally called 
setDefaultUserAgentStylesheet, but a more recent patch included in the 
Jira issue has renamed that to setTheme.

Regarding passing Theme or ThemeName to Application.setTheme().....I'm 
not sure. Using the Theme class forces the developer to become familiar 
with the Theme and Themes classes, which isn't a bad thing. I can also 
appreciate the verbosity of this approach. One compromise is to add a 
convenience method along the following lines to Application:

public final void setTheme(String themeName) {
     setTheme(Themes.getInstance().getTheme(themeName));
}

Thoughts?

-- Jonathan


On 24/04/2012 10:43 a.m., Tom Schindl wrote:
> ServiceLoader is from an OSGi PoV a tough thing to get working. This
> blog post provides some background [1] and a solution but when I read
> bytecode manipulation this sounds scary.
>
> The main problem is that there's no TCCL in an OSGi-Context. I think in
> equinox one could use so called buddy classloading to overcome the
> class-path fences put up by OSGi but I need to check that, felix will
> most likely fail to locate external provided themes completely.
>
> But I don't think this is a problem because you are providing an API to
> register themes so OSGi people can use OSGi-Services and register
> against this API. I can provide as part of e(fx)clipse runtime a central
> point to register themes which calls to your Themes#addTheme-API, OSGi
> Users can add this bundle and are ready to go.
>
> Some minor question in the API why are you is the API on Application
> called setDefaultUserAgentStylesheet and not setDefaultTheme? Would it
> be better to pass the themeId to the method instead of the theme and
> then the internal code does the lookup for the theme and if not found
> falling back to the guaranteed default one.
>
>
> Tom
>
> [1]http://coderthoughts.blogspot.com/2011/08/javautilserviceloader-in-osgi.html
>
> Am 23.04.12 23:58, schrieb Tom Schindl:
>> No - the current threads context classloader is not good! I'll try to
>> take a look at the patch but I'm out for 4 days starting tomorrow so it
>> might take sometime.
>>
>> Tom
>>
>> Am 23.04.12 22:40, schrieb Jonathan Giles:
>>> Oh, I should also note that the patch included with RT-19713 uses
>>> ServiceLoader to bring in any Theme instances provided by external jars,
>>> etc. I would really appreciate if someone more familiar with OSGi, and
>>> its classloader complexities, could provide a comment on whether using
>>> the default classloader (the classloader of the current thread) is
>>> correct, or whether we should be passing in a different classloader.
>>>
>>> Thanks,
>>> Jonathan
>>>
>>> On 24/04/2012 7:59 a.m., Jonathan Giles wrote:
>>>> Hi all (again),
>>>>
>>>> I've put up a very preliminary patch attached to RT-19713 [1] that
>>>> allows for people to set a default user agent stylesheet for their
>>>> entire application. If the default stylesheet is not overridden by the
>>>> developer, then they will be automatically updated to the latest
>>>> stylesheet - should we ever decide to make another one. The main
>>>> driver for this tweak is to prevent JavaFX user interfaces becoming
>>>> stale in the same way Swing user interfaces were stuck using Metal L&F.
>>>>
>>>> Please, if you have time, review the comments in the jira issue itself
>>>> to understand more of the problem space.
>>>>
>>>> Finally, as noted, this is a preliminary patch - there are tweaks to
>>>> be made for sure. Already, David Grieve has commented on the Jira
>>>> issue about suggested changes. I look forward to your suggestions too.
>>>>
>>>> [1] http://javafx-jira.kenai.com/browse/RT-19713
>>>>
>>>> -- Jonathan
>>>>
>>>>
>>>> On 14/03/2012 12:47 p.m., Jonathan Giles 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
>>>>>
>>>>> Thanks,
>>>>> Jonathan
>>
>