On Tue, 22 Apr 2025 21:09:58 GMT, Jeremy Wood <d...@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 <turban...@gmail.com>
>  - Update 
> test/jdk/java/awt/BorderLayout/ConstrainedBorderLayoutChildrenTest.java
>    
>    Co-authored-by: Andrey Turbanov <turban...@gmail.com>
>  - Update 
> test/jdk/java/awt/BorderLayout/ConstrainedBorderLayoutChildrenTest.java
>    
>    Co-authored-by: Andrey Turbanov <turban...@gmail.com>
>  - Update 
> test/jdk/java/awt/BorderLayout/ConstrainedBorderLayoutChildrenTest.java
>    
>    Co-authored-by: Andrey Turbanov <turban...@gmail.com>
>  - Update 
> test/jdk/java/awt/BorderLayout/ConstrainedBorderLayoutChildrenTest.java
>    
>    Co-authored-by: Andrey Turbanov <turban...@gmail.com>
>  - Update 
> test/jdk/java/awt/BorderLayout/ConstrainedBorderLayoutChildrenTest.java
>    
>    Co-authored-by: Andrey Turbanov <turban...@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

Reply via email to