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> 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/
>
> 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> 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/
>>>>
>>>> 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
>
