The trouble with Skins

Tomas Mikula tomas.mikula at
Sat Mar 14 03:33:29 UTC 2015

A quick poll:

Has anyone ever implemented a custom skin for some of the more complex
controls like ListView, TableView, TreeView, TextArea?

The problem I have with the Control/Skin architecture is that a
Control, being a Node in the scene graph, cannot be a pure model (in
the MVC sense) - it is inherently a view (in the MVC sense). What is
the model of a check box? For me, a model of a check box is a boolean
property; certainly not something that has boundsInParent or
onZoomFinished properties. CheckBox is hardly a model. It is a view.
Everything in the scene graph is inherently a view.

There is this idea that the view aspect of a control is implemented by
the skin. The control itself does not know what the skin looks like or
even what skin class is used. So a ListView knows about its items, but
it does not know about its scroll position. But users sometimes want
to know the scroll position. Why should there be onScrollProperty, but
not way to get the current scroll position? Why should there be
TextArea.getBoundsInParent(), but not TextArea.getCaretBounds()? There
is no good way to implement the latter methods using custom skins. The
ListView or TextArea don't know anything about the skin, thus they
don't know anything about the current scroll position or caret bounds.
They cannot ask the skin, because there might be no skin yet, and even
if there is, all they know about it is that it is an instance of
Skin<?> - not much one can do with it (certainly not get caret

I'm leaning more and more towards not supporting custom skins at all.
The whole idea of overriding skins via CSS looks to me like dependency
injection via CSS, except without any possibility to constrain the
type of what can be injected.

I would like to know the community opinion on this. Even hear your
success story how skins are awesome, if there is such.


More information about the openjfx-dev mailing list