RFR: 4811995: BorderLayout does not respect minimum size of its components [v2]
Phil Race
prr at openjdk.org
Sat Apr 26 03:29:46 UTC 2025
On Tue, 22 Apr 2025 21:09:58 GMT, Jeremy Wood <duke at openjdk.org> wrote:
>> This PR changes how the BorderLayout positions components when they don't fit inside a container.
>>
>> This should have no effect on BorderLayouts that match or exceed their preferred size.
>>
>> (The name of this PR/ticket is a little misleading: this in no way relates to `component.getMinimumSize()`.)
>>
>> Here is part of a comment in that ticket that sums up what this PR is trying to fix:
>>> Instead of the South Component being placed partially offscreen as Windows does, it is often placed on top of the North Component. Indeed, BorderLayout.layoutContainer() always places the South Component flush with the bottom of the Container and does not check if the Container is smaller than the minimum size, or if the North and South Components overlap.
>>
>> Previously child components could:
>> A. be assigned negative (x,y) coordinates
>> B. be assigned negative widths or heights
>> C. overlap other child components
>> D. be assigned dimensions that don't fit inside the target container
>>
>> This PR will instead constrain certain values. Now child components may be given a width/height of zero pixels, but they should never show the 4 behaviors stated above.
>>
>> We encountered this basic problem last week at work (we could end up with a component with a negative height). Our work-around was more complex than this PR: we wrote a modified BorderLayout that would switch to using `component.getMinimumSize()` when the preferred size wouldn't fit. IMO that is a better option all-around, but it is dangerously invasive for an OpenJDK proposal. I'm happy to discuss that idea further, though, if anyone here disagrees.
>
> Jeremy Wood has updated the pull request incrementally with six additional commits since the last revision:
>
> - Update test/jdk/java/awt/BorderLayout/ConstrainedBorderLayoutChildrenTest.java
>
> Co-authored-by: Andrey Turbanov <turbanoff at gmail.com>
> - Update test/jdk/java/awt/BorderLayout/ConstrainedBorderLayoutChildrenTest.java
>
> Co-authored-by: Andrey Turbanov <turbanoff at gmail.com>
> - Update test/jdk/java/awt/BorderLayout/ConstrainedBorderLayoutChildrenTest.java
>
> Co-authored-by: Andrey Turbanov <turbanoff at gmail.com>
> - Update test/jdk/java/awt/BorderLayout/ConstrainedBorderLayoutChildrenTest.java
>
> Co-authored-by: Andrey Turbanov <turbanoff at gmail.com>
> - Update test/jdk/java/awt/BorderLayout/ConstrainedBorderLayoutChildrenTest.java
>
> Co-authored-by: Andrey Turbanov <turbanoff at gmail.com>
> - Update test/jdk/java/awt/BorderLayout/ConstrainedBorderLayoutChildrenTest.java
>
> Co-authored-by: Andrey Turbanov <turbanoff at gmail.com>
For (1) I don't know other than "too risky". I considered doing it behind a system property so there is no effect unless you opt in by setting that property. But if it means setting the property is a way to contravene the Java SE spec, we'd not be able to do that. So that seems out too, at least without more analysis to disprove any spec. issues.
We should definitely do (2). I don't think (3) is necessary.
-------------
PR Comment: https://git.openjdk.org/jdk/pull/24772#issuecomment-2831797680
More information about the client-libs-dev
mailing list