The trouble with Skins

[Tomas Mikula]

I could say how I _feel_ differently about some things, but it's not
important how I feel. What is important is that it comes down to
practical problems. The layout details often leak and are not details
anymore. Sometimes you would like to know if an item of a ListView is
currently displayed. Or you want to know item's location on screen, so
that you can position a popup next to it. This is something only the
skin knows.

As said before, Control is not your domain model. We need to go no
further than OpenJFX for evidence: TextArea has a field of type
TextAreaContent, which says "Text area content model". So not even
OpenJFX uses Controls as (domain) models. So what kind of model is it?
Is it a "model of interaction" with the domain model? Layout details
necessarily leak in.

Maybe just being able to specify required type of skin would help: if
TextArea could say that its skin has to implement interface
TextAreaSkin (which has the method getCaretBounds()). Also, I think
skins should be opt-in - not all Controls should be Skinnable by
default.

Tomas

On Sat, Mar 14, 2015 at 3:31 AM, Tom Eugelink <tbee at tbee.org> wrote:
> 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
>
>