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 <[email protected]> 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>
