The trouble with Skins

[Tom Eugelink]

Hi Tomas,

I have looked into it, but not yet attempted, but I did do a lot of custom controls. And I agree that it is dubious that a control is a node, and has the properties that come with it. I try to maintain a strict separation in my controls in JFXtras; controls only have functional methods, the skin and CSS do all the layout. For example the gauge I've ported from Enzo; my version does not have a setFillColor() like the one in Enzo, that is something that the user needs to do through CSS.

That said, if a control were only a model, than it would not be a control, right? We would create model-skins, so there is something that differentiates a control from a model. To me that is an abstraction of the skin. For example: not knowning HOW it is rendered, a textbox does know that it can receive the focus, it is implicit to what it is. So there is a certain logic for allowing controls to have rudimentary rendering info, as long as it does not expose the actual layout details.

Looking at ListView, there is a logic in that a list can scroll, so onScroll on the control makes sense. Whether that scrolling is done via a scrollbar or buttons is a skin detail that should not leak out. So the fact that ListView does not have a scroll position makes sense to me.

Tom


On 14-3-2015 04:33, Tomas Mikula wrote:
> 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
> bounds).
>
> 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.
>
> Regards,
> Tomas