On Wed, 20 May 2026 14:57:08 GMT, Michael Strauß <[email protected]> wrote:
>> It _was_ internal in the original proposal. In fact, we `could` improve the
>> default behavior by adding, let's say, support for arbitrary `Path`s, but
>> with the public factory it's set in stone.
>>
>> I think I should revert the public factory and go back to `null` signifying
>> the default behavior, whatever that is.
>
>> It _was_ internal in the original proposal. In fact, we `could` improve the
>> default behavior by adding, let's say, support for arbitrary `Path`s, but
>> with the public factory it's set in stone.
>>
>> I think I should revert the public factory and go back to `null` signifying
>> the default behavior, whatever that is.
>
> This is the text of your original proposal:
>
>
> /**
> * ...
> * When this property is {@code null}, the menu provides only the basic
> graphic copied from the corresponding
> * {@link Tab} - either an {@link ImageView} or a {@link Label} with an
> {@link ImageView} as its graphic.
> * ...
> */
> public final ObjectProperty<Function<Tab, Node>>
> menuGraphicFactoryProperty() {
>
>
> An observable behavior that is described in documentation can _never_ be an
> internal implementation detail; it is part of the public contract of the
> class. Whether it has its own API element (like a constant field) isn't
> relevant.
Oh, I agree with the sentiment: it's great when the behavior is properly
documented.
But if we can get back to the initial sticky wicket, the use of `null` to
signify the default behavior, I think using `null` is a cleaner solution in
this particular corner case. In most of the use cases, the default is
acceptable and no one cares. But if not, there is a way to override it.
That's it.
I am going to revert the factory and call the property
`menuGraphicFactoryOverrideProperty` to make clear it's an override. How does
that sound?
-------------
PR Review Comment: https://git.openjdk.org/jfx/pull/1773#discussion_r3275083681
