The trouble with Skins

[Tomas Mikula]

So Skins prevent us from getting visual details of the Control (such
as scroll position, position of item on screen, ...), because it is
Skin-specific, but at the same time they fail to customize the look &
feel, because visual presentation leaks into the Control anyway.

On Sat, Mar 21, 2015 at 12:01 PM, John Hendrikx <hjohn at xs4all.nl> wrote:
> On 14/03/2015 08:31, Tom Eugelink 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.
>
>
> As someone that has been tempted to write a new Control that replaces
> ListView atleast half a dozen times now because of restrictions or idioms
> that don't match my needs, I'd disagree.  A ListView doesn't need to scroll
> at all.  An application that isn't mouse or touchscreen controlled (keyboard
> or remote controlled for example) has zero need for scrollbars except maybe
> as information to show the relative size of the view.
>
> A List of items could be paged only, or they could flip.  I'd like to be
> able to take a List, and wrap it in a ScrollBarView... or in a PagerView,
> FlipOverView or CoverFlowView (with 30 new properties to set things like
> reflections, 3d parameters, distance between items, etc).   It is possible
> to do this with Skins, but it feels like a hack rather than simply a
> different Look&Feel in the end.
>
>  After all, a ListView is a container for an unbounded list of items.  I can
> think of half a dozen ways of how that can be shown to the user, and the
> current ListView is just one way to do it.  The promise of Skins here is
> that I could just change the look & feel, but unfortunately way too many
> details of the "default" look & feel leak through in the Control itself.
>
> --John
>
>>
>> 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
>>
>>
>