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

[Jim Weaver]

I am very much in favor of this idea.

Thanks,
Jim Weaver

On 11/21/12 4:05 PM, Jasper Potts wrote:
> The idea is: if there is no skin specified in CSS rather than logging a error like it does today, we first call createDefaultSkin() to create a skin. If it returns null then we log a error the same as we do today for no skin. So you can carry on using css for specifying or overriding the controls skin but it is not compulsory like it has been.
>
> Here is a example for Pagination control.
>
> public class Pagination extends Control {
> ...
>      @Override protected Skin<?> createDefaultSkin() {
>          return new PaginationSkin(this);
>      }
> …
> }
>
> Even if we support "default" as css value we still need some way for control to tell CSS what that default is. So we would still need API like this as there is no way to override a CSS properties default value in a subclass.
>
> I have attached patch for fix to bug http://javafx-jira.kenai.com/browse/RT-25325 . This includes switching all shipping controls over to new method and fixing a couple bugs in control skins that were uncovered by slight change in skin creation timing.
>
> Jasper
>
> On Nov 21, 2012, at 12:43 PM, steve.x.northover at oracle.com wrote:
>
>> So the idea is not to use CSS at all and to reset the default skin?
>> Could we support "default" as a value for -fx-skin instead?
>> Can you give a simple example of how createDefaultSkin() would be used?
>>
>> Steve
>>
>> On 21/11/2012 3:25 PM, Jonathan Giles wrote:
>>> 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


-- 
Regards,
Jim Weaver
Java Evangelist
Oracle Corporation
james.weaver at oracle.com