On Sat, Mar 21, 2015 at 2:10 PM, Tom Eugelink <t...@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 <hj...@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 >>>> >>>> >
