Review request for 7124554: [macosx] JWindow does ignore setAlwaysOnTop property

Anthony Petrov anthony.petrov at oracle.com
Thu Jan 12 05:06:51 PST 2012


Hi Leonid,

Thanks for taking a look at the fix.

The if check is needed for the following case. If the parent window is 
an always-on-top window, its level is NSFloatingWindowLevel. Suppose a 
child window being added to it hasn't been assigned any level 
explicitly, so its default level is NSNormalWindowLevel.

Now, when we call -addChildWindow:, we really want to update the level 
of the child window so that both the parent and the child share the same 
window level. The if check ensures that we don't reset the level of the 
child window back to normal in this case.

--
best regards,
Anthony

On 01/11/12 21:48, Leonid Romanov wrote:
> Just wondering: what would happen if you simply set oldChildlevel without that "if" check?
>
> On 11.01.2012, at 19:22, Anthony Petrov wrote:
>
>> Hello,
>>
>> Please review a fix for http://bugs.sun.com/view_bug.do?bug_id=7124554 at:
>>
>> http://cr.openjdk.java.net/~anthony/x-6-alwaysOnTop.0/
>>
>> Lubomir Nerad (CC'ed) should be credited for the fix itself. I'm just going to integrate it into the repository.
>>
>> A JWindow object is always a child window with either an explicit parent, or a shared invisible owner frame. Therefore, we always call NSWindow -addChildWindow: when showing a JWindow object. The root cause of the issue is that the -addChildWindow: resets the level of the child window to match that of the parent window. With this fix we restore the level back to its original value after the -addChildWindow: call, and as such preserve the always-on-top state of the child window.
>>
>> I've verified the fix with a test app attached to the original issue at http://java.net/jira/browse/MACOSX_PORT-158 , and it works fine.
>>
>> --
>> best regards,
>> Anthony
>


More information about the macosx-port-dev mailing list