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 BorderPane shares some of the calculations with VBox, so it's possible it
is a bug. This small program can reproduce the issue:
.main .button {
-fx-pref-width: 12em;
-fx-pref-height: 12em;
}
package app;
import javafx.application.Application;
import javafx.scene.Scene;
import javafx.scene.control.Button;
import javafx.scene.control.Label;
import javafx.scene.layout.BorderPane;
import javafx.scene.layout.FlowPane;
import javafx.stage.Stage;
public class LayoutBugDemo extends Application {
@Override
public void start(Stage stage) {
BorderPane borderPane = new BorderPane();
FlowPane flowPane = new FlowPane();
flowPane.getStyleClass().add("main");
borderPane.setTop(new Label("Instance Name"));
borderPane.setCenter(flowPane);
flowPane.getChildren().addAll(
new Button("Minecraft"),
new Button("Forge"),
new Button("NeoForge"),
new Button("OptiFine"),
new Button("Fabric"),
new Button("Fabric API"),
new Button("Quilt"),
new Button("SQL/QFAPI")
);
borderPane.setBottom(new Button("Install"));
Scene scene = new Scene(borderPane, 600, 400);
scene.getStylesheets().add("styles.css");
stage.setScene(scene);
stage.setTitle("JavaFX Layout Bug Demo");
stage.show();
}
public static void main(String[] args) {
launch(args);
}
}
-------------
PR Comment: https://git.openjdk.org/jfx/pull/1723#issuecomment-3041190238
