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<t...@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<hj...@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.
