Looks fine.
On 12/01/2019 08:26, Manajit Halder wrote:
Hi Sergey,
As per your suggestion, I have reverted the fix to original state, before the
fix of initial bug (code before fix of issue JDK-7158623 with change set
e0b025915be8). The MAXIMIZED_BOTH frame is now resizable on Mac OS, which is
the default behaviour on Mac OS. The test case is modified to escape execution
on Mac OS. Please review the update webrev:
http://cr.openjdk.java.net/~mhalder/8215280/webrev.02/
Regards,
Manajit
On 09-Jan-2019, at 3:35 AM, Sergey Bylokhov <[email protected]
<mailto:[email protected]>> wrote:
Hi, Manajit.
Why did you drop this check "&& !isMaximizedBoth();" from the
setResizable(resizable)? This change is necessary to fix the bug?
BTW I have started to feel that probably we should not fix initial bug at all
and leave it as is, and by default use the native cocoa behavior
On 07/01/2019 01:57, Manajit Halder wrote:
Hi Sergey,
You are right. I have changed the code to reset the resizable behaviour in
NORMAL state. Please review the webrev:
http://cr.openjdk.java.net/~mhalder/8215280/webrev.01/
Regards,
Manajit
On 05-Jan-2019, at 3:54 AM, Sergey Bylokhov <[email protected]
<mailto:[email protected]>> wrote:
Hi, Manajit.> The fix makes sure a frame after transition due to double click
on title bar from MAXIMIZED_BOTH state to NORMAL state is resizable.
I guess the frame in the NORMAL state should be resizable if it was resizable
before MAXIMIZED_BOTH, but if the user set it to non-resizable before
MAXIMIZED_BOTH then the frame should be non-resizable in a NORMAL state. Can
you check this case, please?
--
Best regards, Sergey.
--
Best regards, Sergey.
--
Best regards, Sergey.
