Hello, Sergey, Anthony.
Thank you for the review. I've updated the fix, the new version is available
here:
http://cr.openjdk.java.net/~pchelko/8026143/webrev.01/
Sergey wrote:
> Is it possible to track this state in the deliverMoveResizeEvent? and update
> the state of the frame accordingly?
This was a great idea. It significantly simplified our implementation.
windowShouldZoom method appears to be VERY unreliable, so checking the state
every time the window is resized works much better.
Anthony wrote:
> src/macosx/classes/sun/lwawt/macosx/CPlatformWindow.java:
>> 577 if (!wasMaximized && isMaximized()) {
>> 578 deliverZoom(true);
>> 579 } else if (target instanceof Frame) {
>
> And other occurrences of deliverZoom: it looks like we call it for any
> CPlatofrmWindow instance, while the extended state is only tracked for Frame
> instances in public API in AWT. Do we have to manage the maximized state for
> Window or Dialog peers?
Actually Dialog javadoc states that it should not receive WindowStateChanged
events.
Window javadoc does not say anything about it. So in the new version we deliver
zoom events only to frames.
With best regards. Petr.
On 09.10.2013, at 22:26, Sergey Bylokhov <[email protected]> wrote:
> Hi, Petr.
> Is it possible to track this state in the deliverMoveResizeEvent? and update
> the state of the frame accordingly?
>
> On 09.10.2013 20:45, Petr Pchelko wrote:
>> Hello, AWT Team.
>>
>> Please review the fix for the issue:
>> https://bugs.openjdk.java.net/browse/JDK-8026143
>> The fix is available at:
>> http://cr.openjdk.java.net/~pchelko/8026143/webrev.00/
>>
>> When the window is created and it's size is bigger/equal to the size of the
>> screen, Cocoa implicitly sets the native zoomed state to true. In
>> JDK-8007219 this state was made consistent with peer level, this fix makes
>> peer-level state consistent with frame level.
>>
>> With best regards. Petr.
>
>
> --
> Best regards, Sergey.
>
