Virtual Flow enhancements

[Scott Palmer]

While reading this I was thinking of a similar, but not quite the same use
case.  A visual Diff program that is showing two versions of the same
source file side-by-side.  Scrolling both views in a synchronized way such
that lines that are the same are aligned is a common feature, but since one
file may have a different number of lines the two sides won't scroll
exactly the same amount to keep the views where you want them. Regardless,
the need for exact positioning between the two views exists.  I haven't
attempted to do this yet, but it is something that may come up soon in a
project I'm working on.  Knowing any relevant tricks or gotcha cases will
be helpful.

Cheers,

Scott

On Fri, Oct 28, 2022 at 8:43 AM Dirk Lemmermann <dlemmermann at gmail.com>
wrote:

> Looks like I missed this last replay from Johan. In my last email I was
> referring to a work-around where one VirtualFlow gets repositioned via
> scrollTo() method calls in response to changes in the other VirtualFlow.
> Not only are the rows alignments way off but updates are lagging behind.
>
> But let’s leave that behind for now and let’s try to find an existing
> property that would make our use-case work again.
>
> For the “FlexGanttFX” use-case where I need to syncronize  the scrolling
> of a TreeTableView and a ListView I would love to be able to simply bind
> the “position” properties of those two controls with each other. That feels
> very intuitive to me. If both controls have the same number of rows and
> each row’s height matches the row’s height in the other control then this
> should work, but currently it does not.
>
> The “position” property gets updated by the VirtualFlow. When the flow
> sets this property to a certain value then I would hope setting the same
> value from outside would place the virtual flow at the exact same position.
> Basically I am hoping that this is a bijective mapping but it is not ….
> unless … the user scrolled all the way down in both views. Then it becomes
> a bijective mapping. So I guess after having made all rows visible the
> calculations are based on hard facts (as in “actual row height”) and not on
> estimates.
>
> To summarise the requirement: there should be a way to bind a property of
> VirtualFlow so that two instances with the same content can be scrolled in
> sync (content = same rows with same heights resulting in same total virtual
> height).
>
> Dirk
>
> On 15 Sep 2022, at 21:20, Johan Vos <johan.vos at gluonhq.com> wrote:
>
>
>
> On Wed, Sep 14, 2022 at 12:19 PM Dirk Lemmermann <dlemmermann at gmail.com>
> wrote:
>
>> Hi,
>>
>>
>> FlexGanttFX used to make this work via bidirectional bindings of the
>> properties of the vertical scrollbars of both VirtualFlows. With the latest
>> fixes to the VirtualFlow the assumption that two identically populated
>> VirtualFlows would provide identical values to the ScrollBar properties is
>> no longer true. The attempt to bind the “position” property also failed and
>> a work-around that Johan provided also has not been successful, yet (a
>> customer of mine is still evaluating it).
>>
>
> I don't know what work-around you refer to, but I often point to public
> methods in VirtualFlow that, when properly combined, allow many usecases. I
> sometimes see code where the information about the positioning of elements
> in the VirtualFlow is obtained via the position of the scrollbar thumb,
> which seems a really odd way to get this info (and especially unreliable as
> the relation with the real positioning of cells is unspecified). There are
> other methods on VirtualFlow that imho are better suited for
> getting/setting information.
> What I want to avoid is that we have 2 API's that almost achieve the same.
> Hence, before considering a new method or property, I think we should make
> sure that there is currently no existing (documented) way to achieve it. I
> am pretty sure there are cases that can not be solved with the existing set
> of API's, and those cases are exactly what I'm looking for.
>
> - Johan
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20221028/808bf426/attachment-0001.htm>