Any volunteers to review the fix?

Thanks in advance,
Dmitry
On 21/04/2016 10:21, dmitry markov wrote:
Hello,

Could you review the fix for jdk9, please?

    bug: https://bugs.openjdk.java.net/browse/JDK-8080729
    webrev: http://cr.openjdk.java.net/~dmarkov/8080729/webrev.00/

Problem description:
On OS X platform in dual monitor setup a child window jumps to another monitor where a parent/owner is displayed.

In CPlatformWindow and CWarningWindow classes we use CWrapper.NSWindow.addChildWindow() and CWrapper.NSWindow.removeChildWindow() during parent-child relationship processing (see setVisible() and orderAboveSiblings() for details). The methods addChildWindow() and removeChildWindow() invoke corresponding Cocoa API (see NSWindow in Cocoa framework). According to Cocoa documentation:

"After a window is added as a child of parent window, it is maintained in relative position indicated by ordering mode for subsequent ordering operations involving either window. While this attachment is active, moving child window will not cause parent window to move, but moving the parent window will cause child window to move."

So negative visual effects such as jumping to another monitor in multi-monitor case, etc. are caused by usage of addChildWindow() and removeChildWindow().

Fix:
Replace CWrapper.NSWindow.addChildWindow() and CWrapper.NSWindow.removeChildWindow() calls with CWrapper.NSWindow.orderWindow() in CPlatformWindow and CWarningWindow classes.

Add several new methods to AWTWindow.m:
- iconifyChilds() is responsible for hiding or showing child windows when parent/owner window is miniaturized or de-miniaturized. - orderChilds() is responsible for child windows ordering. Order operation is based on the current focus state of owner window, (e.g. if owner window is focused, all its child should be ordered above it). - isJavaPlatformWindowVisible() checks visibility of native window from Java layer perspective.

Thanks,
Dmitry

Reply via email to