On Mon, 24 Feb 2025 20:30:17 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 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 FYI: To help with testing, I've added some containers to the monkey tester: https://github.com/andy-goryachev-oracle/MonkeyTest (AnchorPane, BorderPane, FlowPane) and added more options to the HBox/VBox page and add child function and the childrens' context menus. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1723#issuecomment-2679883002
