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