RFR: 8350149: VBox ignores bias of child controls when fillWidth is set to false [v4]

John Hendrikx jhendrikx at openjdk.org
Fri Feb 28 21:30:31 UTC 2025


> Fixes the case where `VBox` will ignore the (horizontal) bias of a child when its fill width property is set to `false`.  This manifests itself with labels that have their wrap text property set to `true`, and the container is not wide enough to hold the text on a single line (in other words, the label is potentially far wider, and fill width should have no effect).  No reflow would occur before this fix.
> 
> The solution is to ensure the `computeChildAreaMin/Pref/MaxHeight` functions are provided with a `fillWidth` parameter, to be used in the case a horizontally biased control is encountered (several of the parameters to these compute functions are only used for those special cases and ignored otherwise).
> 
> With this additional information, the compute functions can decide between the preferred width of a control or the available width of the container.  In the old implementation this decision was made *before* these functions were called, and the available width was reset to -1 to indicate the case that the preferred width should be used.  However, there are three cases, and so setting a single parameter to -1 can't effectively communicate that:
> 
> Assuming a control that is horizontally biased, and is resizable there are three cases when calculating a **height**:
> 
> 1. There is no available width: bias is ignored (as there is no value to use as a dependent value) and the height is then simply calculated ignoring available width (which is -1) and fill width settings (same as unbiased controls).
> 2. There is an available width and fill width is false; the bias logic must first find a reasonable width before it can call any height function; with fill width false, this reasonable width will be the preferred width of the control, unless it exceeds its maximum width or the available width, in which case the smallest of these three values is used.  The final width calculated is then used to determine the height.
> 3. There is an available width and fill width is true; this is the same as case 2, except the available width is used as a dependent value (unless its greater than the child's maximum width, in which case the smaller is used).  The final width calculated is then used to determine the height.
> 
> All in all, this PR removes several inconsistencies between horizontal and vertical computations. The end result is that the horizontal and vertical bias calculations now more closely mirror each other.
> 
> **Note**: some tests have had their values adjusted.  This is becaus...

John Hendrikx has updated the pull request incrementally with one additional commit since the last revision:

  Clarify terms

-------------

Changes:
  - all: https://git.openjdk.org/jfx/pull/1723/files
  - new: https://git.openjdk.org/jfx/pull/1723/files/bbafc21f..87509310

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jfx&pr=1723&range=03
 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1723&range=02-03

  Stats: 4 lines in 1 file changed: 2 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jfx/pull/1723.diff
  Fetch: git fetch https://git.openjdk.org/jfx.git pull/1723/head:pull/1723

PR: https://git.openjdk.org/jfx/pull/1723


More information about the openjfx-dev mailing list