<AWT Dev> [9] Review request for 8080729: [macosx] java 7 and 8 JDialogs on multiscreen jump to parent frame on focus

Thu Apr 28 14:08:49 UTC 2016

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.markov at 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.markov at oracle.com <mailto:dmitry.markov at 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.markov at oracle.com <mailto:dmitry.markov at 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
>>> 
>> 
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/awt-dev/attachments/20160428/359877bb/attachment.html>