[API Review] RT-24916 - TableView.scrollTo(TableColumn)

[Richard Bair]

I agree, one of the things the VirtualFlow is supposed to do is to have a "stable view" regardless of what changes occur in the model. Suppose I have 10,001 items, and have time 5,000 in the middle of the view ports (my position is .5). Whether items 0-4,999 or 5,001->10,001 change heights (unless they all go to 0, but anyway), the view should never change its position (.5) and I should remain centered. However if the 5,000 cell changes height, I shouldn't keep re-centering it.

Also, if I'm on the first cell, any cells below it that change shouldn't change the position. If I'm on the last cell, any cells above it that change shouldn't change the position either.

I remember this was problematic figuring this out "right", but the theory was definitely that you didn't want to unnecessarily move around the position as the heights were changing. The same goes for when things are added / removed. That might cause the position to change (i.e.: if I remove the last 5,001-10,001 items, then 5,000 becomes the last), but we should change the position so that the previous item remains the current item (position would change to 1 so that 5,000 is still the current item).

Richard

On Feb 4, 2013, at 10:57 PM, John Hendrikx <hjohn at xs4all.nl> wrote:

> On 4/02/2013 21:02, Jonathan Giles wrote:
>> This is a fair comment: scrollTo has been designed with a 'fire-and-forget' approach in mind, but I would be loath to add a means of requesting a self-correcting scrollTo function. Wouldn't a suitable workaround be to call scrollTo after the image loading has completed in all cells?
> The problem is that image loading occurs in the background, and it is not really predictable when all of them are completed.  In my example application, these images are loaded from a database (when cached) or from the internet when not.  It may take 10 seconds before one has been loaded if it wasn't cached.  Waiting that long before I restore the position of the view for the user is not acceptable.  Also, calling scrollTo may trigger more image loading (as new cells come into view), so I'd have to call it in a loop until no more images are getting loaded...
> 
> I realize that self-correcting the position seems wierd, but on the other hand, why is the control adjusting position when some cell changes height?  Should the View control not take every effort to stay in the same position?  In other words, if my last interaction with the View class was to tell it "show me cell 313 nicely centered", and then cells 304-312 change their height, should they not simply be pushed up and out of view and keep my cell 313 centered?
> 
> I think it should store its "position" not as some absolute Y coordinate (which would change whenever any intermediate cell changes height), but more relative to the cell.  ie. the position is cell 313, centered at 45% down from the top of the control.  That way when a cell changes, it will try to keep the position stable.
> 
> I cannot predict when image loading will happen, nor when it will finish.  Even if I could, I'd probably have to call scrollTo in a loop for a few times as it would not be acceptable to wait calling it.  Also... as soon as I do call it, other cells are likely to scroll into view, triggering more image loading...
> 
>> Regarding a lower-level API for exact positioning, please file a jira tweak request.
> I've filed http://javafx-jira.kenai.com/browse/RT-28192
> 
> --John