[REVIEW REQUEST] RT-25325 Controls should be hardcoded to their default skin in case -fx-skin is not specified in CSS

Jonathan Giles jonathan.giles at oracle.com
Wed Nov 21 12:25:08 PST 2012


Jasper and I have been speaking about this recently, so from my point of 
view as tech lead inside the UI controls team I believe this is a good 
move - it speeds up instantiation time (less use of the costly 
reflection) and it allows for easier styling, both of which Jasper has 
outlined below. These are both good wins.

The other big perk is that we can release more samples code without 
referring to private API (that is, the skins we use to style our controls).

-- Jonathan

On 22/11/2012 9:17 a.m., Jasper Potts wrote:
> Hi all,
>
> When building applications we often want to remove and replace all the default styling from a control but still use the default skin. To do this so far you had to respecify the default skin in your css file with something like
>
> .my-button {
> 	-fx-skin: "com.sun.javafx.scene.control.skin.ButtonSkin";
> }
>
> The problem with this is the skins are in a com.sun package so not public API and may change in the future. So what I propose doing is adding new protected method to Control class so that sub-classes can create instances of their default skin.
>
> public abstract class Control{
> …...
>      /**
>       * Create a new instance of the default skin for this control. This is called to create a skin for the control if
>       * no skin is provided via CSS {@code -fx-skin} or set explicitly in a sub-class with {@code  setSkin(...)}.
>       *
>       * @return  new instance of default skin for this control. If null then the control will have no skin unless one
>       *          is provided by css.
>       */
>      protected Skin<?> createDefaultSkin() ….
> ….
> }
>
> The reason for returning a instance rather than class name string is it speeds up start up to not have to do the reflection to lookup and instantiate the class from classname. It would have been nice if this could have been a abstract method but that would have not been backwards compatible.
>
> All existing code will work as it does not but any css specifying the default skin can now be removed when running on 8.
>
> Thanks
>
> Jasper



More information about the openjfx-dev mailing list