The trouble with Skins

[Tom Eugelink]

I don't understanding how you see that.


On 21-3-2015 18:47, Tomas Mikula wrote:
> 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
>>>