On Fri, 21 Nov 2025 08:40:18 GMT, Marius Hanl <[email protected]> wrote:
>>> is to take another look at the problem and how to solve it. >> >> The RTA design is that VFlow deals with the layout. It views the thing not >> as a collection of independent cells, but as a virtual flow - a change in >> one cell might require the reflow of many other parts, toggling scroll bars >> visibility, reshaping the selection shapes, etc. >> >> In an ideal world, the layout of text and embedded nodes would be a >> responsibility of the (prism) text layout, making it easier to have for >> example a Label with rich text. But we don't have that option, so this >> design uses a collection of text cells to present the visible area, managed >> by the VFlow. > > Let me repeat what I mean: > - If you call: `setManaged(false)`, you will effectively tell JavaFX: I'm the > layout root, I can handle ALL layout changes from my children without my > parents. > - This is not the case here, so making the `TextCell` unmanaged while still > retrieving a parent (`VFlow`) fights this design. > - Which leads me to the conclusion: Maybe this should not be unmanaged, since > it does not fulfill the required preconditions > - Checking the `VirtualFlow` as an example, it will not set anything to > unmanaged > > Lets check some existing examples of unmanaged nodes: > > `XYChart`. See how this was done by design, the consequences were known: > https://github.com/openjdk/jfx/blob/33abf5d4b3d2b90f66581c4e25c542adf285fadd/modules/javafx.controls/src/main/java/javafx/scene/chart/XYChart.java#L523-L525 > > --- > > `ScrollPaneSkin` has actually the same case as you. This is how they dealt > with it: > https://github.com/openjdk/jfx/blob/33abf5d4b3d2b90f66581c4e25c542adf285fadd/modules/javafx.controls/src/main/java/javafx/scene/control/skin/ScrollPaneSkin.java#L652-L653 > https://github.com/openjdk/jfx/blob/33abf5d4b3d2b90f66581c4e25c542adf285fadd/modules/javafx.controls/src/main/java/javafx/scene/control/skin/ScrollPaneSkin.java#L679-L689 > > This could be a solution for your problem. Since they also set the parent > `viewRect` as unmanaged, the layout request will never hit the `ScrollPane`. > But with that solution the child of the `viewRect`, called `viewContent` does > request the `ScrollPane` layout. A clever solution without anything like > ancestor searching. What do you think? The documentation on `Node.managed` property states Defines whether or not this node's layout will be managed by its parent. The layout of TextCell is not managed by its parent (`VFlow.content`), **by design**. The `VFlow` is the entity that does the layout, for a reason. It's a complicated thing, and multiple moving parts are connected (one example: it performs multiple layout cycles in the same layout pass when scrollbars appear/disappear during the layout pass, to avoid jumping and flicker - something we occasionally see with `ScrollPane` and `ListView`, see Note 1). Notes 1. I occasionally see the continuous flicker/layout when resizing the list of pages in the latest Monkey Tester, but so far I was unable to capture the exact conditions to create a reproducible test case (this is unrelated to this PR) ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1975#discussion_r2550174581
