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.mar...@oracle.com
<mailto: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).
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.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
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
