<AWT Dev> [9] Review Request: 7124365 [macosx] setMaximizedBounds() should be implemented

[Petr Pchelko]

Hello, Alexander.

Thank you for testing!

> I noticed that a window doesn't move on setExtendedState(Frame.MAXIMIZED_BOTH) if a window already have
> the same size as provided to setMaximizedBounds(). 
Hmm.. didn’t notice that.. Looks like it’s because we are discarding zoom the size is not going to change.
Looks like I should reimplement a fix with unrealizable windows.

About #2 - thank you. I’ll update this.

With best regards. Petr.

15 апр. 2014 г., в 6:01 после полудня, Alexander Zvegintsev <alexander.zvegintsev at oracle.com> написал(а):

> Hello Petr,
> 
> 
> #1:
> I noticed that a window doesn't move on setExtendedState(Frame.MAXIMIZED_BOTH) if a window already have
> the same size as provided to setMaximizedBounds(). 
> 
> Another case: 
> we successfully maximized a window, its window state is MAXIMIZED_BOTH,
> we moved a window, its window state is NORMAL
> we trying to maximize it once again, window state becomes MAXIMIZED_BOTH, but window keeps its location.
> 
> I think, that a user would expect that the window will be moved to its MaximizedBounds location.
> 
> #2:
> 
> I suggest to place check against javaMaxSize above javaMinSize in AWTWindow.m.
> 
> IIRC, on Windows, Linux and Mac OS X min size native hint is more powerful than max size. So after applying native hints like
> 
> frame.setMinimumSize(new Dimension(300, 300));
> frame.setMaximumSize(new Dimension(200, 200));
> 
> the size of a frame will be 300x300 (java currently supports maximum size on OS X only, but you can check it with any native program).
> 
> And calling
> 
> frame.setMaximizedBounds(new Rectangle(300, 300, 500, 500));
> 
> will lead to a window with size 200x200, but I expect here 300x300 (anyway I think that it is a ridiculous case).
> 
> But just moving this checks isn't enough because of #1 (a window has size same to specified in setMaximizedBounds() and doesn't move).
> 
> 
> Thanks,
> 
> Alexander.
> On 04/15/2014 04:33 PM, Petr Pchelko wrote:
>> Hello, AWT Team.
>> 
>> Please review the fix for the issue:
>> https://bugs.openjdk.java.net/browse/JDK-7124365
>> The fix is available at:
>> http://cr.openjdk.java.net/~pchelko/9/7124365/webrev/
>> 
>> The implementation is pretty straightforward. 
>> In native -1 indicates that this bound is not set. Using Integer.MAX_VALUE as in Frame’s javadoc isn’t convenient in native code.
>> We do not need to worry about bounds that do not fit the screen - Cocoa handles it for us.
>> But we need to handle the maximum/minimum sizes manually, because these are applied before the willUseStandardFrame callback is called.
>> The regression test for this exists, it’s being moved from SQE right now. I’ll modify it to support Mac as soon as it’s pushed.
>> 
>> Thank you.
>> With best regards. Petr.
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/awt-dev/attachments/20140415/64949c00/attachment.html>