On Tue, 20 Jan 2026 21:30:01 GMT, Andy Goryachev <[email protected]> wrote:
> Thank you for clarifications! > > I also suspect I did not get my point across about storing the layout > properties in the node vs. the layout container. What happens when the code > moves the node with these properties to another similar container? Nothing happens, just like for the past 15 years. The properties can live on there, until they're needed again when the node becomes part of a layout container. > Whose responsibility it is to clear the unrelated properties and why is this > needed in the first place? This falls on the user, as they're the ones setting these properties, if they care (they don't stack up, there is a fixed number of them) and leaving them alone doesn't break anything. So, there is no need to clean them at all. It's exceedingly rare that a Node is re-used in such a way that this would matter (ie. moving a Node from a HBox to a GridPane, instead of what usually happens, which is just to recreate the Node). > If the property (grid index, growth priority) makes no sense outside of the > particular container, why is it stored in the node as opposed to let's say a > hashtable within the layout container? This makes no sense to me, but okay, > it's grandfathered like any other weird thing in FX. But why add more weird > code on top of weird code? Using a hash table actually makes this worse. Reparenting or temporarily removing a node would mean you also have to move or reconstruct its constraints, or lose them entirely. With attached properties, the metadata naturally travels with the node. In practice this case is rare anyway, so it shouldn’t carry much weight in the design discussion. Swing’s choices predate modern UI frameworks, and its designers were involved in creating JavaFX, so they clearly understood the trade-offs. Since then, almost all modern UI frameworks have converged on the attached-property style, including modern web layout via CSS. FX already follows this model, which is great as it was conceived over 15 years ago. What’s weird is not that layout metadata lives on the node, but that it’s exposed only through static setters instead of real, styleable, observable properties. Continuing this design would remove some of the weirdness, not add to it. It would also allow these properties to integrate cleanly with the CSS engine, opening up an entirely new way of controlling layout, where there exists a huge gap now. ------------- PR Comment: https://git.openjdk.org/jfx/pull/2015#issuecomment-3775153409
