On Fri, 28 Feb 2025 21:30:31 GMT, John Hendrikx <jhendr...@openjdk.org> wrote:
>> 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 va... > > John Hendrikx has updated the pull request incrementally with one additional > commit since the last revision: > > Clarify terms The changes look correct to me as does my testing. I left a minor question or two, but nothing that needs to be addressed before integration. ------------- Marked as reviewed by kcr (Lead). PR Review: https://git.openjdk.org/jfx/pull/1723#pullrequestreview-2711271059
