Virtual Flow enhancements

[Dirk Lemmermann]

FWIW: I have created a GitHub repository that showcases three different approaches to performing synchronised scrolling between two VirtualFlow instances: https://github.com/dlemmermann/sync-scrolling <https://github.com/dlemmermann/sync-scrolling>

Might come in handy for future testing if anyone thinks they know how it could be done. Each demo creates “rows” (cells) of different heights, which I guess is one of the tricky things about it.

One approach is the one that I have been using for FlexGanttFX for the last couple of years. The second one is related to it (using the positionProperty()), the third one is the one that Johan started / suggested (scrollTo()).

Dirk


> On 13 Sep 2022, at 11:02, Johan Vos <johan.vos at gluonhq.com> wrote:
> 
> Hi,
> 
> OpenJFX 17 contains a fix for JDK-8089589  [1] ([ListView] ScrollBar content moves toward-backward during scrolling.) Before this fix, the scrollbar in the VirtualFlow backing List/Table/TreeTableView controls was treating every cell of equal height. That generated an awkward scrolling experience, especially when there are major differences in sizes in the backing list.
> 
> The original fix introduced some new issues, and most of these are meanwhile fixed, and tests are added (thanks to e.g. Florian Kirmaier who created a good amount of tests). 
> 
> However, people have in the past been relying on undocumented behavior while creating apps and libraries, and that behavior is not guaranteed anymore with the fix for JDK-8089589 that went into OpenJFX 17. 
> Most of these cases are related to 
> (1) assuming that IndexedCell.updateItem() is only called when an item is (about to be) shown and
> (2) assuming that the value returned by the positionProperty of the scrollbar thumb is linearly related to the index of the item in the backinglist being shown.
> 
> Both of these assumptions are invalid, but were (more or less) happening before JavaFX 17. 
> I have seen a fair amount of creative implementations that somehow get and process information about the position of elements in the controls. Some of these relied on the false assumptions above, and are obviously no longer working.
> Instead of providing fixes per case, I think it would be good to capture the common use cases, and make it easier for developers to achieve what they want to achieve. I didn't yet encounter a use case that can not be implemented with the current approach (using public API's only), but granted, implementations often require too much boilerplate and wiring code. 
> 
> Crucial in this exercise are tests. There are a fair amount of tests for the list/table/treetableview controls, but only few of them are focused on external access and behavior. 
> For all the fixes done so far in VirtualFlow, additional tests have been written which are now excellent regression tests. The last thing we want is that a fix for usecase A is not working anymore after a fix for usecase B.
> 
> Hence, I'd like us to do 2 things:
> 1) for issues that are clearly bugs (*violating the JavaDoc*), please create JBS issues as usual (with failing test code). 
> 2) for issues that are not violating the specs now, but are "common sense", please create a description and test scenario with expected versus actual outcome. 
> 
> I am not 100% sure what the best approach is to tackle issues that fall in the second category, but I suggest this: if you have a rather vague, abstract issue (e.g. "listview should always scroll to the bottom of the list IF it was at the bottom before and a new element is added") , it probably makes sense to first discuss it here. If on the other hand you have a very clear issue with a clear failing test, it can be a JBS issue as well -- but we need to keep in mind then that it might be in the category of "this fixes usescase A but blocks usecase B"
> 
> Thanks,
> 
> - Johan
> 
> [1] https://bugs.openjdk.org/browse/JDK-8089589 <https://bugs.openjdk.org/browse/JDK-8089589>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20220915/d7c956f8/attachment.htm>