> 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 with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains two additional commits since the last revision: - Merge branch 'openjdk:master' into feature/vbox-fillwidth-bug-fix - Make computeChildMin/Pref/MaxAreaHeight accept a fillWidth parameter ------------- Changes: - all: https://git.openjdk.org/jfx/pull/1723/files - new: https://git.openjdk.org/jfx/pull/1723/files/33500bab..b55c20e9 Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1723&range=01 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1723&range=00-01 Stats: 779078 lines in 8295 files changed: 648376 ins; 72616 del; 58086 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
