I see, thanks.
Last thing I was wondering: Shall we try to encapsulate the new logic
into a non-public component (that extends from Region or StackPane or
something?) and use that in ScrollPaneSkin and VirtualFlow?
So that we do not have much duplicate or very similar looking code in
both classes.
Or are both classes too different that this does not make sense?
-- Marius
On 9/7/26 10:56 PM, Michael Strauß wrote:
ScrollPaneSkin and VirtualFlow don't need to know about the different
transitions, but the orchestration logic is still substantial. The
scroll orchestrator will be factored out, but both classes interact
strongly with the orchestrator and thus require quite a lot of
changes. There is a certain amount of irreducible complexity inherent
in this feature.
On Mon, Sep 7, 2026 at 10:24 PM Marius Hanl <[email protected]> wrote:
I like this idea.
With your proposed interface, is it possible that the complete logic is
handled inside the ScrollTransition, e.g. all the ScrollPane need to do
is call a method on ScrollTransition?
Just wondering how much the ScrollPane need to "know" about the
transitions, so need code to account for that (or maybe for all possible
cases), or the changes are more concentrated on the ScrollTransition
itself and the containers only manage the property and delegate to it.
-- Marius
