On Tue, 20 Jan 2026 22:02:07 GMT, John Hendrikx <[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? Whose
>> responsibility it is to clear the unrelated properties and why is this
>> needed in the first place? 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?
>>
>> So I am not convinced: the use case you mentioned is just too abstract, and
>> nothing tells me that it can't be implemented using existing APIs. What is
>> the problem you are trying to solve, apart from some unnamed "tools"? These
>> tools can simply query the `Node.getProperties()` for these properties,
>> given the keys are Strings, can't they?
>
>> 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.
> Thank you @hjohn this example makes sense.
>
> So, if I understand it correctly, the proposal is to add two-tiered styleable
> properties? Are there limitations as to which attached property is legal for
> which node, or any attached property (including custom) can be attached to
> any node?
There can be limitations. For example, `HeaderBar.prefButtonHeight` can only be
attached to `Stage`, while layout constraints can only be attached to `Node`.
The restriction is indicated by the target parameter of the static accessor,
for example:
class HBox {
public static void setMargin(Node node, Insets value);
}
This proposal formalizes a target-type restriction with the `AttachedProperty`
interface:
interface AttachedProperty {
Class<?> getTargetClass();
}
If you're given a property instance, this allows you to then query the class of
objects for which it can be set.
-------------
PR Comment: https://git.openjdk.org/jfx/pull/2015#issuecomment-3775172871
