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