Hi Petr,
src/macosx/native/sun/awt/AWTWindow.m
125 @synthesize preFullScreenLevel;
126 @synthesize javaMaximizedBounds = _javaMaximizedBounds;
The style of instantiation of the javaMaximizedBounds property differs
from a bunch of other properties. Is there any particular reason for
that? Do we need to change other @synthesize directives above this one
as well?
255 self.javaMaximizedBounds = NSMakeRect(-1, -1, -1, -1);
In a multi-screen environment, could -1 indicate a valid value for a
coordinate that user code might actually want to use?
1033 if (y >= 0) {
The specification of Frame.setMaximizedBounds() allows a developer to
provide some of the fixed parameters only (e.g. the width and the x
coordinate), leaving others set to their default, system-provided
values. So the condition you're checking here seems incorrect.
--
best regards,
Anthony
On 4/15/2014 4: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.
