On Tue, 5 Nov 2024 06:00:55 GMT, Michael Strauß <mstra...@openjdk.org> wrote:
>> modules/javafx.graphics/src/main/java/javafx/application/ConditionalFeature.java
>> line 156:
>>
>>> 154: * Indicates that a system supports {@link
>>> javafx.stage.StageStyle#EXTENDED}.
>>> 155: * <p>
>>> 156: * This feature is currently supported on Windows, Linux, and
>>> macOS.
>>
>> would it make sense to add more information similarly to UNIFIED_WINDOW on
>> L151?
>> maybe pointing to different levels of support?
>>
>> I don't know whether it makes sense to bring the whole table from the JEP
>> here, but maybe somewhere (HeaderBar)?
>
> It links directly to `StageStyle.EXTENDED`, which contains lots of
> information. I don't think we need it here.
>
> By the way, there are no support levels. The feature is supported in its
> entirety, as specified, on all desktop platforms. The table in the JEP is
> just informational to help OpenJFX developers understand what we're talking
> about. It's not a specification, and it can't be a specification because we
> either don't control things (for example, we have no influence on rounded
> corners, this could be changed with any future OS version) or because we'd be
> specifying us into a corner. There's no point prescribing every minute
> detail, and then being responsible to keep it working _exactly_ as described,
> even though the semantics are unchanged.
>
> The relevant parts are specified in `StageStyle.EXTENDED` and `HeaderBar`,
> and I wouldn't go further than this. We don't specify the details of
> `StageStyle.DECORATED` for each OS; why should we do it for
> `StageStyle.EXTENDED`?
I guess you are right here: from the app dev perspective, there is no
difference between the supported platforms. All good.
I do suggest to bring a condensed version of the table in the JEP (or a simple
<ul> here to show what's being painted by the platform and what is not. In
other words, instead of reading 1k of text, I want to see a short list
indicating that, for example, close button is painted by the platform, and the
title bar is not painted.
Can you do something like this? (Alternatively, there might be a better place
to do that, but where?)
>> modules/javafx.graphics/src/main/java/javafx/scene/layout/HeaderBar.java
>> line 53:
>>
>>> 51: * account for the default window buttons (minimize, maximize, close).
>>> If a child is configured to be
>>> 52: * centered in the {@code center} area, it is laid out with respect to
>>> the stage, and not with respect
>>> 53: * to the {@code center} area. This ensures that the child will appear
>>> centered in the stage regardless
>>
>> should there be more fine tuned control for growing/shrinking?
>>
>> can the application just add a single container like GridPane that handles
>> the resizing?
>
> What do you mean with growing and shrinking?
>
> An application can add a single `GridPane` to `HeaderBar.center`, and set its
> prefWidth to `POSITIVE_INFINITY`. This will extend the `GridPane` across the
> entire width of the header bar (excluding the window button area).
maybe what's needed is to borrow some text from the `BorderPane`, along the
lines of
> "The top and bottom children will be resized to their preferred heights and
> extend the width of the border pane. The left and right children will be
> resized to their preferred widths and extend the length between the top and
> bottom nodes. And the center node will be resized to fill the available space
> in the middle. Any of the positions may be null. "
the important parts are
- how children are resized
- any can be null
(the layout in the HB is like the one in the `BorderPane`, right?)
>> modules/javafx.graphics/src/main/java/javafx/scene/layout/HeaderBar.java
>> line 59:
>>
>>> 57: * {@code HeaderBar} honors the minimum, preferred, and maximum sizes
>>> of its children. If the child's
>>> 58: * resizable range prevents it from be resized to fit within its
>>> position, it will be vertically centered
>>> 59: * relative to the available space; this alignment can be customized
>>> with a layout constraint.
>>
>> what if the components are too large to fit, will clipping occur? should
>> this behavior be mentioned?
>
> The components can't be too large to fit:
> `{@code HeaderBar} honors the minimum, preferred, and maximum sizes of its
> children.`
I want to know what happens when the layout is over-constrained. For example,
consider the layout to have the leading, the center, and the trailing nodes
set, and the leading one has minWidth set to 10_000. What happens?
Will the center and the trailing nodes be shown or clipped? will the layout
attempt to squeeze all three to fit the available space?
Can I get this answer from the javadoc?
-------------
PR Review Comment: https://git.openjdk.org/jfx/pull/1605#discussion_r1829645476
PR Review Comment: https://git.openjdk.org/jfx/pull/1605#discussion_r1829654387
PR Review Comment: https://git.openjdk.org/jfx/pull/1605#discussion_r1829666593
