Hello, Anthony. > Please file a separate issue to investigate the setBounds/zoom code on Mac > later.
I have filed https://bugs.openjdk.java.net/browse/JDK-8027250 With best regards. Petr. On 24.10.2013, at 18:04, Anthony Petrov <[email protected]> wrote: > Hi Petr, > > The workaround you suggest seems to be more or less safe, so let's go with it. > > Please file a separate issue to investigate the setBounds/zoom code on Mac > later. > > -- > best regards, > Anthony > > On 10/23/2013 01:05 PM, Petr Pchelko wrote: >> Hello, Anthony. >> >>> What happens if you display a decorated frame centered on the screen? Will >>> it receive the initial Move/Size event? And if yes, why exactly this isn't >>> happening for undecorated frames? >> Yes. The decorated frame is receiving the initial move/resize event. I >> suppose it's somehow moved(resized) be adding the window decorations, but >> this is only a guess. >> >> With best regards. Petr. >> >> On 23.10.2013, at 12:56, Anthony Petrov <[email protected]> wrote: >> >>> Hi Petr, >>> >>> What happens if you display a decorated frame centered on the screen? Will >>> it receive the initial Move/Size event? And if yes, why exactly this isn't >>> happening for undecorated frames? >>> >>> Also, at [1] Alexander said: >>>> The problem was that NSWindow is created with zero bounds and then >>>> actual bounds are set. >>>> In this case NSWindow treats big bounds as zoomed state and next zoom >>>> move the window to initial zero bounds. >>> >>> I'm wondering, won't the same scenario fail for undecorated windows after >>> your fix, just reverting them back to 0x0/1x1 instead of 0x0/0x0? >>> >>> [1] >>> http://mail.openjdk.java.net/pipermail/awt-dev/2013-September/005469.html >>> >>> -- >>> best regards, >>> Anthony >>> >>> On 10/23/2013 12:43 PM, Petr Pchelko wrote: >>>> Hello, AWT Team. >>>> >>>> Please review the fix for the issue: >>>> https://bugs.openjdk.java.net/browse/JDK-8027025 >>>> The fix is available at: >>>> http://cr.openjdk.java.net/~pchelko/8027025/webrev.00/ >>>> >>>> The problem: >>>> When initializing the peer's location and bounds we rely on the initial >>>> move/resize event. However if the undecorated frame is created right at >>>> the center of the screen this initial event does not come. >>>> My testing shows that this is an only situation. >>>> >>>> The solution: >>>> We revert the changes in JDK-8007219 for undecorated frames. The initial >>>> position is a 0-0-1-1 stub, the real position is set later during the >>>> initialization. >>>> I don't want to do that for decorated frames as 1. this is not needed 2. >>>> the native maximize button starts working ugly in some cases. >>>> >>>> With best regards. Petr. >>>> >>
