<html>
<head>
<meta content="text/html; charset=UTF-8" http-equiv="Content-Type">
</head>
<body text="#000000" bgcolor="#FFFFFF">
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.<br>
<br>
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. <br>
<br>
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.<br>
<br>
<div class="moz-cite-prefix">On 28/04/2016 17:08, Anton Tarasov
wrote:<br>
</div>
<blockquote
cite="mid:DE408DF8-5C05-4B7F-8E4A-33828F20A505@jetbrains.com"
type="cite">
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
<div class="">Ok, thanks for the explanation. My assumption about
putting "main/key” window to the floating level was wrong.</div>
<div class=""><br class="">
</div>
<div class="">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).</div>
<div class=""><br class="">
</div>
<div class=""><br class="">
<div>
<blockquote type="cite" class="">
<div class="">On 28 Apr 2016, at 16:24, dmitry markov <<a
moz-do-not-send="true"
href="mailto:dmitry.markov@oracle.com" class="">dmitry.markov@oracle.com</a>>
wrote:</div>
<br class="Apple-interchange-newline">
<div class="">
<meta content="text/html; charset=UTF-8"
http-equiv="Content-Type" class="">
<div text="#000000" bgcolor="#FFFFFF" class=""> Anton,<br
class="">
<br class="">
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).<br class="">
<br class="">
Usually all Java windows/frames/dialogs have the normal
level. <br class="">
<br class="">
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 <a moz-do-not-send="true"
class="moz-txt-link-freetext"
href="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</a>).
Also we explicitly order each children above its nearest
owner using orderWindow() function, see code fragment
below:<br class="">
<pre class=""><font class="" color="#3333ff">[window orderWindow:NSWindowAbove relativeTo:[owner.nsWindow windowNumber]];</font></pre>
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().<br class="">
<br class="">
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.<br class="">
<br class="">
So for your example: A<-B<-C relationship and
A,C,B sequence (assume A has just received focus) we
will get something following:<br class="">
1. A stays at the normal window level<br class="">
2. C is moved to the floating level and ordered above B<br
class="">
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)<br class="">
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<br class="">
</div>
</div>
</blockquote>
<div><br class="">
</div>
<div>Is it true that reordering B still keeps C above it? If
so, then the scheme works.</div>
</div>
</div>
</blockquote>
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. <br>
Anyway I think this case is outside the scope of the fix and should
be investigated under separate bug, if any.<br>
<br>
Thanks,<br>
Dmitry<br>
<blockquote
cite="mid:DE408DF8-5C05-4B7F-8E4A-33828F20A505@jetbrains.com"
type="cite">
<div class="">
<div><br class="">
<blockquote type="cite" class="">
<div class="">
<div text="#000000" bgcolor="#FFFFFF" class=""> <br
class="">
I agree the comments inside orderChilds() are not clear
and may confuse. I updated the fix, new version is
located at <a moz-do-not-send="true"
class="moz-txt-link-freetext"
href="http://cr.openjdk.java.net/%7Edmarkov/8080729/webrev.02/">http://cr.openjdk.java.net/~dmarkov/8080729/webrev.02/</a><br
class="">
Summary of change:<br class="">
- Renamed orderChilds() and iconifyChilds() to
orderChildWindows() and iconifyChildWindows()
accordingly<br class="">
- Added some comments to orderChildWindows()<br class="">
</div>
</div>
</blockquote>
<div><br class="">
</div>
<div>Ok, looks fine to me.</div>
<div><br class="">
</div>
<div>Regards</div>
<div>Anton.</div>
<br class="">
<blockquote type="cite" class="">
<div class="">
<div text="#000000" bgcolor="#FFFFFF" class=""> <br
class="">
Thanks,<br class="">
Dmitry<br class="">
<br class="">
<div class="moz-cite-prefix">On 28/04/2016 11:40, Anton
Tarasov wrote:<br class="">
</div>
<blockquote
cite="mid:4B538F41-946A-409D-8ACA-542B3271EB7D@jetbrains.com"
type="cite" class="">
<meta http-equiv="Content-Type" content="text/html;
charset=UTF-8" class="">
Hi Dmitry,
<div class=""><br class="">
</div>
<div class="">Honestly, I don’t clearly understand how
it works now.</div>
<div class=""><br class="">
</div>
<div class="">With A<-B<-C relationship and
A,C,B sequence:</div>
<div class=""><br class="">
</div>
<div class="">1. C is ordered above B (we get: A-C-B)</div>
<div class="">2. B is ordered above A (we get: B-A-C)</div>
<div class=""><br class="">
</div>
<div class="">So, C ordering is lost. Or I'm missing
something?</div>
<div class=""><br class="">
</div>
<div class="">Also, can you please clarify the
following.</div>
<div class=""><br class="">
</div>
<div class="">
<pre style="background-color: rgb(238, 238, 238);" class=""><span class="new" style="color: blue;">+ if (focus) {</span>
<span class="new" style="color: blue;">+ // Place the child above the owner</span>
<span class="new" style="color: blue;">+ [window setLevel:NSFloatingWindowLevel];</span>
<span class="new" style="color: blue;">+ } else {</span>
<span class="new" style="color: blue;">+ // Place the child to the owner's level</span>
<span class="new" style="color: blue;">+ [window setLevel:NSNormalWindowLevel];</span>
<span class="new" style="color: blue;">+ }</span></pre>
<div class="">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?</div>
<div class=""><br class="">
</div>
<div class="">And also, if you modify the code
further, may be you rename “Childs” in the new
methods to “Children” or to “ChildWindows”?</div>
<div class=""><br class="">
</div>
<div class="">Thanks,</div>
<div class="">Anton.</div>
<div class=""><br class="">
<div class="">
<blockquote type="cite" class="">
<div class="">On 28 Apr 2016, at 10:06, dmitry
markov <<a moz-do-not-send="true"
href="mailto:dmitry.markov@oracle.com"
class="">dmitry.markov@oracle.com</a>>
wrote:</div>
<br class="Apple-interchange-newline">
<div class="">Hi Anton,<br class="">
<br class="">
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).<br class="">
Please find new version here: <a
moz-do-not-send="true"
href="http://cr.openjdk.java.net/%7Edmarkov/8080729/webrev.01/"
class="">http://cr.openjdk.java.net/~dmarkov/8080729/webrev.01/</a><br
class="">
<br class="">
Thanks,<br class="">
Dmitry<br class="">
On 27/04/2016 13:46, Anton Tarasov wrote:<br
class="">
<blockquote type="cite" class="">Hi Dmitry,<br
class="">
<br class="">
The fix looks fine to me, still I have
some concern...<br class="">
<br class="">
Say, we have windows with the following
relationship: A<-B<-C
(owner<-child). Then the ordering is
executed for A:<br class="">
<br class="">
- We’ve got a sequence: A, B, C.<br
class="">
- A is skipped, B is ordered above A, C is
ordered above A<br class="">
<br class="">
Am I right that C will be ordered above B
(as it should be) eventually?<br class="">
<br class="">
Is that possible that we get a sequence:
A, C, B? And then B will be ordered above
C which is incorrect?<br class="">
<br class="">
Thanks,<br class="">
Anton.<br class="">
<br class="">
<blockquote type="cite" class="">On 25 Apr
2016, at 22:35, dmitry markov <<a
moz-do-not-send="true"
href="mailto:dmitry.markov@oracle.com"
class="">dmitry.markov@oracle.com</a>>
wrote:<br class="">
<br class="">
Any volunteers to review the fix?<br
class="">
<br class="">
Thanks in advance,<br class="">
Dmitry<br class="">
On 21/04/2016 10:21, dmitry markov
wrote:<br class="">
<blockquote type="cite" class="">Hello,<br
class="">
<br class="">
Could you review the fix for jdk9,
please?<br class="">
<br class="">
bug: <a moz-do-not-send="true"
href="https://bugs.openjdk.java.net/browse/JDK-8080729"
class="">https://bugs.openjdk.java.net/browse/JDK-8080729</a><br
class="">
webrev: <a moz-do-not-send="true"
href="http://cr.openjdk.java.net/%7Edmarkov/8080729/webrev.00/" class="">http://cr.openjdk.java.net/~dmarkov/8080729/webrev.00/</a><br
class="">
<br class="">
Problem description:<br class="">
On OS X platform in dual monitor setup
a child window jumps to another
monitor where a parent/owner is
displayed.<br class="">
<br class="">
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:<br class="">
<br class="">
"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."<br class="">
<br class="">
So negative visual effects such as
jumping to another monitor in
multi-monitor case, etc. are caused by
usage of addChildWindow() and
removeChildWindow().<br class="">
<br class="">
Fix:<br class="">
Replace
CWrapper.NSWindow.addChildWindow() and
CWrapper.NSWindow.removeChildWindow()
calls with
CWrapper.NSWindow.orderWindow() in
CPlatformWindow and CWarningWindow
classes.<br class="">
<br class="">
Add several new methods to
AWTWindow.m:<br class="">
- iconifyChilds() is responsible for
hiding or showing child windows when
parent/owner window is miniaturized or
de-miniaturized.<br class="">
- 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).<br
class="">
- isJavaPlatformWindowVisible() checks
visibility of native window from Java
layer perspective.<br class="">
<br class="">
Thanks,<br class="">
Dmitry<br class="">
</blockquote>
</blockquote>
</blockquote>
<br class="">
</div>
</blockquote>
</div>
<br class="">
</div>
</div>
</blockquote>
<br class="">
</div>
</div>
</blockquote>
</div>
<br class="">
</div>
</blockquote>
<br>
</body>
</html>