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

[Jonathan Giles]

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?

Regarding a lower-level API for exact positioning, please file a jira 
tweak request.

Thanks,
-- Jonathan

On 5/02/2013 12:02 a.m., John Hendrikx wrote:
> Hi,
>
> I'm not specifically commenting on this API, but I do would like to 
> comment on the usefulness of scrollTo() in general.
>
> I've found that scrollTo() is very unreliable when cells are not 
> fixed-height, and are still in flux (ie, images being loaded in the 
> background) after the call to scrollTo().  Basically, what is 
> happening is:
>
> 1) Create control, populate model
> 2) Call scrollTo() / focus() to restore the previous position the user 
> left the control/cursor at
> 3) More images get loaded, cells change height and the View moves 
> accordingly but completely ignores the last scrollTo() call and 
> currently focused cell and ends up at some random location (with the 
> focused item often not even in View).
> 4) User has to take a navigation action to get the focused item 
> visible again
>
> I donot know of any acceptable work-arounds, as the problem is mainly 
> that the scrollTo() call is a fire-and-forget type action that will be 
> completely lost when Cells are still in flux.  What it should do is 
> remember this position and keep adjusting the View when no other form 
> of input overrides the current location (keyboard, mouse scrolling, 
> scrollbars).
>
> Furthermore, scrollTo(), although a nice high level API, does not 
> allow me to "return" to an exact previous state (where the exact 
> scroll position of the control is restored).  I'd have to keep the 
> control in memory to be able to provide this functionality, instead of 
> just creating it when needed and positioning it back to where it was.  
> This occurs for example when Views are used for navigation purposes 
> where when an item is selected a different set of items is displayed.  
> Navigating back restores the previous set of items, but unfortunately 
> not the exact position the user came from.
>
> All this is currently leading me into the direction of reskinning the 
> TreeView control, with the goal of providing  reliable and stable 
> behavior when it comes to dealing with cells that are in flux.
>
> --John
>
> On 04/02/2013 09:25, Tom Schindl wrote:
>> hi,
>>
>> We (Jonathan and myself) are requesting an API review to add the
>> following public APIs:
>>
>> New APIS:
>> ---------
>> * ListView:
>>    scrollTo(T) : void
>>
>> * TableView:
>>    scrollTo(S) : void
>>    scrollToColumn(TableColumn<S, ?>) : void
>>    scrollToColumnIndex(int) : void
>> setOnScrollToColumn(EventHandler<ScrollToEvent<TableColumn<S, ?>>>): 
>> void
>>    getOnScrollToColumn() : EventHandler<ScrollToEvent<TableColumn<S, 
>> ?>>>
>>    onScrollToColumnProperty():
>> ObjectProperty<EventHandler<ScrollToEvent<TableColumn<S, ?>>>>
>>
>> * TreeTableView
>>    scrollToColumn(TableColumn<S, ?> column) : void
>>    scrollToColumnIndex(int columnIndex) : void
>> setOnScrollToColumn(EventHandler<ScrollToEvent<TreeTableColumn<S, ?>>>
>> value) : void
>>    getOnScrollToColumn() : 
>> EventHandler<ScrollToEvent<TreeTableColumn<S, ?>>>
>>    onScrollToColumnProperty() :
>> ObjectProperty<EventHandler<ScrollToEvent<TreeTableColumn<S, ?>>>>
>>
>> * ScrollToEvent:
>>    static <T extends TableColumnBase<?, ?>> scrollToColumn() :
>> EventType<ScrollToEvent<T>>
>>
>> Modified APIS:
>> --------------
>> To align better we'd like to change the ScrollToEvent-API to be
>> consitent and use static accessor methods instead of public static 
>> fields:
>>    * SCROLL_TO_NODE => scrollToNode() : EventType<ScrollToEvent<Node>>
>>    * SCROLL_TO_TOP_INDEX => scrollToTopIndex() :
>> EventType<ScrollToEvent<Integer>>
>>
>>
>> Thanks
>>
>> Jonathan + Tom
>>
>