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

[Anthony Petrov]

Hi Mike,

I recall we've discussed this issue with you back in 2010. 
Unfortunately, I wasn't able to implement anything like this that would 
work reliably back then (and I tried hard, really), that's why we ended 
up with -addChildWindow:. Note that JCK is very happy with this 
implementation, and so are we, I presume. As long as child windows 
receive their respective MOVE events, it seems that everything is all 
right. Besides, such behavior is very Mac-friendly, making Java apps 
behave like native apps.

I realize that for some developers this behavior may be inconvenient. 
But then again, why not listen to MOVE events on the parent frame and 
compensate for its movement repositioning all its children? ( :) yeah, 
yeah, I know, sounds weird, but... as Steve says, you gotta do what you 
gotta do... I mean, there's a workaround at least!)

So, if you or anyone else wish to contribute an alternative 
implementation for owned windows, that would be greatly appreciated. 
Otherwise I'm afraid we have to stick with using -addChildWindow: for 
now since we simply don't have a better solution.

--
best regards,
Anthony

On 1/12/2012 11:17 PM, Mike Swingler wrote:
> Also, you should not use -addChildWindow:, because you also get added to the movement group of the parent (moving the parent moves all it's children). This is *highly* undesirable behavior for Java's general use (and you can see it in Eclipse when the find window follows around the IDE window like a puppy).
> 
> In the Java SE 6 AWT we manually restack every Java window in native with -orderFront: every time a Java window changes it's level to correctly handle it's children and the relationships between them. This actually works out ok, since all the changes happen at once, and when the next turn of the event loop happens, the new stacking order only has one new window moving to the background and one new window becoming key/main.
> 
> Regards,
> Mike Swingler
> Apple Inc. 
> 
> On Jan 12, 2012, at 6:34 AM, Leonid Romanov wrote:
> 
>> Bah, I was wrong. The value of NS*WindowLevel is really funky, it was a wrong suggestion to rely on it. Sorry for wasting your time.
>>
>>
>> On 12.01.2012, at 17:52, Anthony Petrov wrote:
>>
>>> The values of the NS*WindowLevel macros are not a part of the contract for Cocoa API. Therefore, we shouldn't rely on their current numerical values. The names, however, and their relative z-order are clearly specified in the documentation, and as such we may use them.
>>>
>>> --
>>> best regards,
>>> Anthony
>>>
>>> On 01/12/12 17:44, Leonid Romanov wrote:
>>>> I see… It looks like the higher window level is, the higher is the value of corresponding NS*WindowLevel macro.
>>>> Wouldn't it be better to implement compareWindowLevels() by simply subtracting one value from another?
>>>>
>>>> On 12.01.2012, at 17:06, Anthony Petrov wrote:
>>>>
>>>>> 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
>