On Fri, 21 Nov 2025 15:39:39 GMT, Andy Goryachev <[email protected]> wrote:
>> 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) Did you read what I wrote above? I made multiple suggestions as how we can deal with the situation, even without making things managed again. To reiterate, what is the problem? - We now have a dependency from `TextCell` to `VFlow`. Not explicitly, but rather hidden, by searching all parents (which is also costly when doing that often). I would prefer a clear separation of concerns - This makes subclassing/extending harder. What happens, if I want to write my own `VFlow`, but still use everything else, including `TextCell`? What if I want to use `TextCell` for a component, that has no `VFlow`? What happens if we find a `VFlow` from another component even? Because we used the `TextCell` somewhere else? - Other components made it clear how to use `managed` and `unamanged` nodes. And how to bubble up a request still. Why do we want to make an exception here? This is the first time we need to search the parent hierarchy - Why not e.g. binding to the `needsLayoutProperty` from a `TextCell` from within `VFlow` and just request the layout when set? Also another point: The test is green for me with the changes from: https://github.com/openjdk/jfx/pull/1945 So I would like to know, if maybe there was a bug even? ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1975#discussion_r2553234576
