Styling HBox/VBox/GridPane child properties (hgrow, margin, columnIndex, etc)

[John Hendrikx]

I took a bit of a closer look.  Although I think I can provide real
properties, there will likely be quite a lot of edge cases with
properties created on demand, and which only should exist while a Node
lives under a certain Parent.  So, I think for an initial version, it
would be best NOT to expose a static property providing method on
HBox/VBox/GridPane as this would allow users to add listeners and bind
to them, making an already complex life cycle even more so.  I think the
feature will be incredibly useful even without this functionality.
Exposing the properties, and providing support for full
binding/listening will likely result in a disproportional amount of time
invested there for something that is very niche at best.

Although you can currently listen to (and modify) these properties via
the Observable properties map, the keys and stored data used by the
various implementations are not part of any public API, so I feel that
we can change how this works without restriction.

That said, transitions will probably work now, however, looking at the
type of properties, none of these seem suitable candidates for any
reasonable form of transition (most are booleans or enums, a few
margins, and a few integers for row/column indices/spans).

TLDR; I will be going for (transitionable) properties internally, but
without exposing them as part of this feature, with a warning that if
ever exposed, the impact of binding/listening needs to be thoroughly
investigated

--John

On 13/02/2025 00:21, John Hendrikx wrote:
> Yeah, it may be possible to do this; as said, I'm already storing a
> StyleableProperty in the map (as it is needed to track the style origin
> for the CSS system, otherwise it will never reset it when styles
> changes), and exposing this property via a static property method would
> certainly be trivial to do.  
>
> Currently I'm storing the property and actual value in separate keys,
> but I suppose there is no reason to have a separate key if the property
> would hold the value.  I think that storing only a property would be a
> better solution, perhaps with some code to avoid creating the property
> similar to how lazy properties are done currently.
>
> This sounds promising, I'll look into it and see if I can get this
> incorporated in the PoC.
>
> --John
>
> On 12/02/2025 20:10, Michael Strauß wrote:
>> Maybe we can expand static properties to complete JavaFX properties.
>>
>> Right now, static properties are implemented with a getter and setter
>> on the declaring class. We can add an additional property getter like
>> so:
>>
>> class HBox {
>>     public static ObjectProperty<Insets> marginProperty(Node child);
>>     public static void setMargin(Node child, Insets value);
>>     public static Insets getMargin(Node child);
>> }
>>
>> Instead of storing the value directly in the properties map, we would
>> store the ObjectProperty instead. In doing that, we can use the
>> Styleable{Double,Object,...}Property implementations, which gives us
>> access to the transition machinery.
>>
>>
>> On Wed, Feb 12, 2025 at 3:27 PM John Hendrikx <john.hendrikx at gmail.com> wrote:
>>> Thanks,
>>>
>>> I may need some help with the transition part when the time arrives. In
>>> CssStyleHelper these parent defined properties are treated no different
>>> from any other properties, but I think some of the transition logic is
>>> part of the properties themselves and I didn't implement that so far.
>>>
>>> How I've implemented them currently is with just-in-time properties that
>>> only implement StyleableProperty (so it's not a full property that could
>>> be bound).  The actual storage is in the properties map associated with
>>> all Nodes.
>>>
>>> I'll see if I can work this up as a PR over the weekend.  It works
>>> already, but needs some polishing and perhaps some optimization as its
>>> part of CSS code.