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

Jonathan Giles jonathan.giles at oracle.com
Mon Feb 4 19:22:28 PST 2013

ScrollPane is a general purpose container to allow for scrolling a 
larger item within a smaller viewport - what we need internally for 
list/tree/table/treetable is a very specialised container for very 
performant and memory efficient layout of cells.

In other words, you're putting words in my mouth if you're claiming that 
I said ScrollPane is the solution for every scrollpane-like requirement! 
:-) Use it if it suits your requirements, and roll your own if it 
doesn't. I would not suggest using the implementation we use for the 
virtualised controls as it will almost certainly be overkill unless 
you're looking to do something very similar to what is done in the 
virtualised controls.

Anywho, regarding the API for scrollTo, lets take that to Jira to thrash 
out rather than bother everyone on list.

And, ideally, it would be great to also have discussion on what Tom 
proposed in the original email! :-)

-- Jonathan

On 5/02/2013 4:16 p.m., Scott Palmer wrote:
> Interesting.. Though it makes me think: If *you* needed something more complex than ScrollPane for those controls, what makes you think *I* don't need the same?
> :-)
> I say this after already implementing my own ScrollPane from scratch via ScrollBars and fancy translations and clipping. (I had to work around some flickering issues in 2.2)
> The three points you have below seem like a reasonable starting point for that discussion though.
> Scott
> On 2013-02-04, at 10:05 PM, Jonathan Giles <jonathan.giles at oracle.com> wrote:
>> Unfortunately it is a little bit more complex than this - ListView, TreeView, TableView, and TreeTableView are all virtualised and do not use ScrollPane internally, and certainly I don't want to expose the actual internal implementation (it is rather complex).
>> Therefore I'd rather have a discussion (probably best via Jira) on what API is desired in these controls. The kind of feature requests I occasionally hear include:
>> * Support for determining what cell is at a given x/y position (for mouse input)
>> * Support for getting the current x/y scroll position (as an offset from (0,0))
>> * Support for setting the x/y scroll position (as an offset from (0,0))
>> -- Jonathan
>> On 5/02/2013 4:00 p.m., Scott Palmer wrote:
>>> We shouldn't add an API for exact positioning to ListView or TableView.  ScrollPane already has this... If the implicit ScrollPane in these controls were exposed, we could have all sorts of fun.
>>> Scott
>>> On 2013-02-04, at 3:02 PM, Jonathan Giles <jonathan.giles at oracle.com> 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?
>>>> 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

More information about the openjfx-dev mailing list