The trouble with Skins

[Tomas Mikula]

On Sat, Mar 21, 2015 at 2:10 PM, Tom Eugelink <tbee at tbee.org> wrote:
> 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,

I suppose this part is clear?

>> but at the same time they fail to customize the look &
>> feel, because visual presentation leaks into the Control anyway.

This is a summary of John's email.

Tomas

>>
>> 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
>>>>
>>>>
>