The trouble with Skins

[John Hendrikx]

For me, I'd like to simply change the Look and Feel and have the same 
data presented differently (perhaps related to space restrictions, 
orientation, user preferences).  Currently, this can be achieved by 
changing the Control, or maybe only change the Skin, depending on how 
radical the transformation is.  I'd like that to be the same thing for 
all these cases and have the same general API (show item X, get 
position, set position, go to first item, go to last item).

If Skins aren't intended for that (despite being able to change the 
complete appearance and even change all the navigation handling), then 
fine -- we'll need to do it with Controls, and have "similar" controls 
all implement the same interface.

ListView looked to me like a very close match, that just needs a small 
push to get what I want (re-implementing all the "virtual" cell logic is 
not something I want to do  for every "skin").  It could be shown as 
pages easily (with a nice pager in the top right corner something).  
This does not affect the API.  I can still call "show item X", or ask 
for it to give me an object that represents the current position (making 
it possible to restore it there later).  I don't need to know it is page 
based, or even know the page number -- just like I don't need to know 
there are scrollbars or what the current scroll position is.  What I do 
need however is a way to restore the control to the exact same state it 
was in before (the same amount of pixels scrolled, the same item at the 
top, the same item at the bottom).

--John

On 21/03/2015 20:32, Scott Palmer wrote:
> My point is that there are many ways to display the same data set, but they shouldn't all be crammed into a single control type. Particularly one that changes radically based on the skin just because the data model can be represented by the same data structure.  For a ListView it could still fit if it was a list that "scrolled" a page at a time,  perhaps that was a bad example. I would still expect the control to be a Node and to have direct access via the control to the current "scroll" position. I would not expect a ListView to have a page-based API, nor would I expect to get access to such an API by accessing the Skin. The skin is an implementation detail that should remain distinct from how my program interacts with the control.
>
> Scott
>
>> On Mar 21, 2015, at 2:53 PM, Tom Eugelink<tbee at tbee.org>  wrote:
>>
>> A page based view can perfectly be a list view; I would have no problem having a paging skin or a scrollbar skin for ListView.
>>
>>
>>
>>> On 21-3-2015 19:46, Scott Palmer wrote:
>>> But that's not right.  A *List* is 'a container for an unbounded list of items".  A ListView is a specific type of control that gives you a view to that list *in a specific way*.  It has properties in addition to the list itself.  It *should* have a scroll position because that is a property of that kind of control - even though the skin will implement it. These controls are visible elements and must expose properties that will ultimately be implemented in the skin. They must be Nodes.  Otherwise they will be far too cumbersome to use.
>>>   You may not need to expose where the scroll bars are, or get access to arrow buttons, etc., but you should have access to what items are visible, what the scroll position is, etc.  you should be able to change the scroll position programmatically without knowing the skin.
>>>
>>> A page based view is a different kind of control. It can still use a List model, but flipping to a page system from a scrollable list is not something I would expect when changing the look and feel.  I might expect to have the view change from pixel-based scrolling to line based scrolling, or have up/down arrows at one end of the scroll bar instead of each end.
>>>
>>> Scott
>>>
>>>> On Sat, Mar 21, 2015 at 12:01 PM, John Hendrikx<hjohn at xs4all.nl>  wrote:
>>>>
>>>> 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.