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

[steve.x.northover at oracle.com]

We fought this one in SWT and ended up going with the puppy route.

Steve

On 12/01/2012 2:57 PM, Anthony Petrov wrote:
> 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
>>