<AWT Dev> [9] Review request for 8080729: [macosx] java 7 and 8 JDialogs on multiscreen jump to parent frame on focus
dmitry markov
dmitry.markov at oracle.com
Fri Apr 29 07:32:53 UTC 2016
Anton,
Thank you for the review.
Can anyone else review the fix, please?
Thanks,
Dmitry
On 29/04/2016 10:25, Anton Tarasov wrote:
> On 29 Apr 2016, at 09:50, dmitry markov <dmitry.markov at oracle.com
> <mailto:dmitry.markov at 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.markov at oracle.com
>>>> <mailto: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, (see
>>>> 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/
>>>> 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
>>>>>>>>> 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/20160429/b3036177/attachment-0001.html>
More information about the awt-dev
mailing list