Future of Skins

David Grieve david.grieve at oracle.com
Mon Jan 27 06:17:46 PST 2014

On Jan 25, 2014, at 5:54 AM, John Hendrikx <hjohn at xs4all.nl> wrote:

> On 24/01/2014 22:28, David Grieve wrote:
>> On Jan 24, 2014, at 4:02 PM, John Hendrikx<hjohn at xs4all.nl>  wrote:
>>> I've got an update on this.
>>> I've rewritten the code now to make use of multiple skins, and doing some trickery with Factories to make them easily switchable.
>>> The main reason I've rewritten them is because I think I will not be able to provide CSS properties that are accessible if they are not specifically defined on a Skin class (or Control class) -- but that may be lack of understanding how CSS properties are discovered (I don't see how they could get discovered if they're defined on a "delegated skin").
>> A control returns the CssMetaData of its skin (provided the skin extends from SkinBase).  Also, if a node is in the scene-graph, then CSS will "discover" it.
> Yes, and a Skin could return the CssMetaData for a Skin it delegates to... my problem is, if I change the delegate (by changing a property) while the main Skin itself remains the same, can I inform the CSS engine of potential changes in the CssMetaData?  Each delegate Skin may have additional CSS properties.  When changing a Skin on a Control that's probably automatic, but I'm not so sure how that would work with a delegate skin.

The getCssMetaData() method is called quite frequently, so it is beneficial to return either a static list, or at least not recreate the list on each call. Control creates the list the first time the method is called, but then the list is set to null when the skin changes so that the list is recreated the next time it is called and will include the skin's cssMetaData. 

In your situation, where the skin remains the same, the way Control works is a problem. The list itself is private to Control and the list that is returned is unmodifiable. Further, getCssMetaData() is final in Control. So some changes would need to be made in Control to support your paradigm. Perhaps an ObservableList property for the the css meta-data list, the implementation of which would take care of informing the CSS engine of changes in the CssMetaData

More information about the openjfx-dev mailing list