Hi,Petr.
The fix looks good.
On 24.10.2013 18:16, Petr Pchelko wrote:
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.
--
Best regards, Sergey.
