Ok, thanks for the explanation. My assumption about putting "main/key” window to the floating level was wrong.
Can you please clarify the following as well. Why ordering everything at a normal level won’t work? For the example below, B & C will both appear at the floating level, though they have owner/child relationship (that is they will be ordered at the same level). > On 28 Apr 2016, at 16:24, dmitry markov <dmitry.mar...@oracle.com> wrote: > > Anton, > > Let me clarify the implementation of orderChilds() function. It is > responsible for proper windows ordering, (i.e. child windows should be always > placed/ordered above their parents or owners; a parent/owner window should > not overlap its children during sizing or moving operations). > > Usually all Java windows/frames/dialogs have the normal level. > > When a window receives focus, (i.e. becomes 'main/key' window), we will look > for all its children and move them to the floating level. According to Cocoa > documentation: floating windows always appear in front of normal-level > windows, > (seehttps://developer.apple.com/library/mac/documentation/Cocoa/Reference/ApplicationKit/Classes/NSWindow_Class/#//apple_ref/occ/instp/NSWindow/level > > <https://developer.apple.com/library/mac/documentation/Cocoa/Reference/ApplicationKit/Classes/NSWindow_Class/#//apple_ref/occ/instp/NSWindow/level>). > Also we explicitly order each children above its nearest owner using > orderWindow() function, see code fragment below: > [window orderWindow:NSWindowAbove relativeTo:[owner.nsWindow windowNumber]]; > When a window loses focus, (i.e. resigns 'main/key' window status), we will > look for its children and move them back to the normal level. And of course > we order each child window above its nearest parent using orderWindow(). > > Please note: orderChilds() function changes window level only for child > windows of current 'main/key' window, (i.e. focus owner); the window level of > 'main/key' is not affected. > > So for your example: A<-B<-C relationship and A,C,B sequence (assume A has > just received focus) we will get something following: > 1. A stays at the normal window level > 2. C is moved to the floating level and ordered above B > 3. B is moved to the floating level and ordered above A (actually ordering > operation does not matter here since A and B are located at different levels) > 4. C and B are displayed in front of A due to different window levels; C is > appeared above B due to ordering call at step 2 Is it true that reordering B still keeps C above it? If so, then the scheme works. > > I agree the comments inside orderChilds() are not clear and may confuse. I > updated the fix, new version is located at > http://cr.openjdk.java.net/~dmarkov/8080729/webrev.02/ > <http://cr.openjdk.java.net/~dmarkov/8080729/webrev.02/> > Summary of change: > - Renamed orderChilds() and iconifyChilds() to orderChildWindows() and > iconifyChildWindows() accordingly > - Added some comments to orderChildWindows() Ok, looks fine to me. Regards Anton. > > Thanks, > Dmitry > > On 28/04/2016 11:40, Anton Tarasov wrote: >> Hi Dmitry, >> >> Honestly, I don’t clearly understand how it works now. >> >> With A<-B<-C relationship and A,C,B sequence: >> >> 1. C is ordered above B (we get: A-C-B) >> 2. B is ordered above A (we get: B-A-C) >> >> So, C ordering is lost. Or I'm missing something? >> >> Also, can you please clarify the following. >> >> + if (focus) { >> + // Place the child above the owner >> + [window setLevel:NSFloatingWindowLevel]; >> + } else { >> + // Place the child to the owner's level >> + [window setLevel:NSNormalWindowLevel]; >> + } >> Am I right that the reason you place the child to the floating level is >> because the “main/key” window is there? If so, then the comment is somewhat >> confusing. You don’t really put the child above the owner with that call. >> With both the calls you simply put the child to the owner’s level. Is that >> correct? >> >> And also, if you modify the code further, may be you rename “Childs” in the >> new methods to “Children” or to “ChildWindows”? >> >> Thanks, >> Anton. >> >>> On 28 Apr 2016, at 10:06, dmitry markov <dmitry.mar...@oracle.com >>> <mailto:dmitry.mar...@oracle.com>> wrote: >>> >>> Hi Anton, >>> >>> Thank you for your feedback. You are right, in some cases B may be ordered >>> above C and that is incorrect. I have updated the fix to eliminate this. >>> Now we order a window above its nearest parent/owner, (i.e. B is ordered >>> above A, C is ordered above B). >>> Please find new version here: >>> http://cr.openjdk.java.net/~dmarkov/8080729/webrev.01/ >>> <http://cr.openjdk.java.net/%7Edmarkov/8080729/webrev.01/> >>> >>> Thanks, >>> Dmitry >>> On 27/04/2016 13:46, Anton Tarasov wrote: >>>> Hi Dmitry, >>>> >>>> The fix looks fine to me, still I have some concern... >>>> >>>> Say, we have windows with the following relationship: A<-B<-C >>>> (owner<-child). Then the ordering is executed for A: >>>> >>>> - We’ve got a sequence: A, B, C. >>>> - A is skipped, B is ordered above A, C is ordered above A >>>> >>>> Am I right that C will be ordered above B (as it should be) eventually? >>>> >>>> Is that possible that we get a sequence: A, C, B? And then B will be >>>> ordered above C which is incorrect? >>>> >>>> Thanks, >>>> Anton. >>>> >>>>> On 25 Apr 2016, at 22:35, dmitry markov <dmitry.mar...@oracle.com >>>>> <mailto:dmitry.mar...@oracle.com>> wrote: >>>>> >>>>> 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 >>>>>> <https://bugs.openjdk.java.net/browse/JDK-8080729> >>>>>> webrev: http://cr.openjdk.java.net/~dmarkov/8080729/webrev.00/ >>>>>> <http://cr.openjdk.java.net/%7Edmarkov/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 >>> >> >
