On 29 Apr 2016, at 09:50, dmitry markov <dmitry.mar...@oracle.com> wrote: > > The main idea of suggested implementation is to keep 'main/key' window in > normal window level and move all its child windows to floating level. Such > approach guarantees that the child windows will appear in front of 'main/key' > window and 'main/key' window will not overlap them when it is resized, moved, > etc. It is supported by native OS and requires less changes in our code. > > Of course we can implement similar logic without usage of floating window > level, but that solution will be quite complex and requires many changes in > the code. In other words we will have to maintain the correct windows order > (child window should be above parent window) by ourselves after every resize, > move and similar operations. Also there are some scenarios where it is quite > difficult or almost impossible to detect that ordering is required due to > native OS limitation. > > Based on above I believe the usage of floating window level is more suitable > for this case. Also as far as I know Windows OS uses quite similar window > level concept to process parent-child relationship.
Ok, got it, sounds reasonable to me. > > On 28/04/2016 17:08, Anton Tarasov wrote: >> 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 >>> <mailto: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, (see >>> https://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. > Frankly I am not sure about this. I performed several tests with various > numbers of child windows and their sequences. I was not able to reproduce the > situation when child window is appeared behind its parent. So if you have any > test case for this, please let me know and I will look into it. > Anyway I think this case is outside the scope of the fix and should be > investigated under separate bug, if any. I don’t have any contra-scenarious at the moment, so let's rely on your testing results then… Thanks! Anton. > > Thanks, > Dmitry >> >>> >>> 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/%7Edmarkov/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 >>>>> >>>> >>> >> >
