On Sun, 9 Aug 2026 09:35:21 GMT, John Hendrikx <[email protected]> wrote:
>> modules/javafx.graphics/src/main/java/javafx/scene/layout/Measurable.java
>> line 75:
>>
>>> 73: * For a vertical content-bias callers should pass in a height
>>> value that
>>> 74: * the minimum width should be based on. For a horizontal or null
>>> content-bias
>>> 75: * the caller should pass in -1.
>>
>> I haven't looked much at the original code, but us there a way to not give
>> the caller a chance to pass the wrong value?
>> For example, if this method checks itself the content bias, and if it's
>> horizontal it treats the input as -1.
>> Usually when you want the user to use a method in some way, it's best to
>> force it. So, if a method says "the super method must be called first", one
>> way of doing it would be:
>>
>> void calc() {
>> super.calc();
>> finish();
>> }
>>
>> abstract void finish();
>>
>> and the user doesn't need tp implement `calc()` themselves.
>
> The caller has some control here based on its own content bias. For example,
> an `HBox` containing both horizontal and vertically biased controls has to
> pick one or the other (it will favor horizontal). For the children that were
> vertically biased, that means they should do a normal calculation -- if such
> children would internally decide that because they have a bias they should
> first calculate the other axis, then the layout wouldn't be correctly
> horizontally biased overall.
>
> Also, callers may not have the information of the size of the other axis (or
> deliberately omitted it due to their own bias), or may want to make
> adjustments to the value queried of a child (ensuring it is within min/max
> range, or filling it out with a larger value if filling is allowed). A biased
> control on its own just doesn't have enough context to decide what the other
> axis value should be for a biased calculation.
>
> This is also a pretty fundamental part of any `Node` that implements the
> `computeMin/Pref/Max/Width/Height` methods -- it can't be changed now to work
> differently even if we wanted to.
Also, the "helper" `computeChildMin/Pref/MaxAreaWidth/Height` methods basically
are what you are suggesting -- they take care of handling this correctly, it
just can't be baked into, say, all `Region` subtypes directly.
-------------
PR Review Comment: https://git.openjdk.org/jfx/pull/2241#discussion_r3743389177
