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
