I cannot reproduce the problem with a build from Dmitry and with a clean
build with a patch for jdk8u-dev from Dmitry.
Thank you,
Denis.
On Thu, May 5, 2016 at 2:59 PM, Denis Fokin <denis.fo...@gmail.com> wrote:
> Hi AWT team,
>
> I used the next test to reproduce the problem
>
> ===== OwnedWindowTest.java ======
>
> public class OwnedWindowTest {
> public static void main(String[] args) {
> SwingUtilities.invokeLater(new Runnable() {
> @Override
> public void run() {
> final JFrame jFrame = new JFrame("Owner frame");
>
>
> jFrame.setDefaultCloseOperation(WindowConstants.DISPOSE_ON_CLOSE);
> jFrame.setSize(new Dimension(500,500));
>
> final JDialog jDialog = new JDialog(jFrame, "Owned
> dialog", false);
> jDialog.setSize(new Dimension(200,200));
>
> jFrame.setVisible(true);
>
> jDialog.setVisible(true);
> }
> });
>
> }
> }
>
> ======== End of OwnedWindowTest.java ======
>
>
> My configuration:
>
> Hardware Overview:
>
> Model Name: MacBook Pro
> Model Identifier: MacBookPro10,2
> Processor Name: Intel Core i5
> Processor Speed: 2,6 GHz
> Number of Processors: 1
> Total Number of Cores: 2
> L2 Cache (per Core): 256 KB
> L3 Cache: 3 MB
> Memory: 8 GB
> Boot ROM Version: MBP102.0106.B0A
> SMC Version (system): 2.6f59
> Sudden Motion Sensor:
> State: Enabled
>
> OS El Capitan
> Version 10.11.4
>
> External Display:
>
> Apple Thunderbolt Display
> 27-inch (2560 x 1440)
> Intel HD Graphics 4000 1536 MB graphics
>
> Thank you,
> Denis.
>
> On Wed, May 4, 2016 at 4:26 PM, Denis Fokin <denis.fo...@gmail.com> wrote:
>
>> Hi AWT team,
>>
>> thank you for the great effort in resolving the issue.
>>
>> I tried the fix (webrev.02) with the latest jdk8u-dev repository.
>>
>> I have found the next regressions:
>>
>> 1. Run a test case. JFrame + owned JDialog. Move the frame to the
>> secondary monitor. Move the dialog to the main dialog. Click on the frame
>> title. Press and hold dialog title. The dialog jumps on the secondary
>> screen. Release the mouse button. The dialog jumps to the main screen.
>>
>> 2. Sometimes, the dialog does not return back to the secondary screen.
>>
>> 3. I do not remember exact scenario, but once, the dialog became minified
>> (folded into title).
>>
>>
>> It looks like the fix require further improvement.
>>
>> I personally, do not like all these add/remove machinery. Keeping z-order
>> model in awt and placing all windows in the NSNormalWindowLevel
>> level seems the best solution to me. Otherwise, we will get constant
>> regressions.
>>
>> Thank you,
>> Denis.
>>
>>
>> On Thu, Apr 28, 2016 at 4:24 PM, dmitry markov <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
>>>
>>> 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()
>>>
>>> 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>
>>> 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
>>>
>>>
>>>
>>>
>>>
>>
>
