Review request for 7142120: [macosx] Some JCK tests for SplashScreen fail on Mac OS X due to incorrect positioning of the splash

[Gregg Wonderly]

This seems very distracting to me, to have the screen sliding around, without 
the users "control".   This can cause focus changes and very gnarly results for 
people who are constantly multitasking, quickly switching between contexts.

I have a JDK6 app, in particular, which is a network app, and when it 
disconnects, it pops up a dialog telling the user this occurs.  That dialog, 
pops up on the active screen, I think, but the problem is, that if I click on 
the window (on another screen), it switches me to the screen with the dialog.  
If I then try to click on the dialog button, the app BEEPS at me when I click 
"okay".  The only way to close the app, is to move the app to the screen that 
the dialog is on.

Somehow, this should all work "better", in terms of managing how "context" 
sensitive actions are joined with the context of a window/frame component.

When a dialog is brought up, and made "current", it steals focus.  If I am touch 
typing, and type a "space", the dialog closes before I can read it.  I'd really 
like to have something different happen, and for example, just having the 
jumping icon in the app bar would be quite indicative of me needing to take 
action on something.

Gregg Wonderlyw

On 2/7/2012 7:48 AM, Alexander Zuev wrote:
> Looks Ok to me (assuming that even if we start program on the second screen 
> the splashscreen should have been placed on main screen where dock and menu 
> bar are).
>
> WBR,
> Alex
>
> On 2/6/12 19:49, Anthony Petrov wrote:
>> Hi Artem,
>>
>> BTW, the updated webrev is at 
>> http://cr.openjdk.java.net/~anthony/x-14-splashScreen-7142120.1/
>>
>> Please find my comments inline.
>>
>> On 2/6/2012 8:17 PM, Artem Ananiev wrote:
>>>
>>> On 2/3/2012 5:22 PM, Anthony Petrov wrote:
>>>> Hello,
>>>>
>>>> Please review a fix for http://bugs.sun.com/view_bug.do?bug_id=7142120 at:
>>>>
>>>> http://cr.openjdk.java.net/~anthony/x-14-splashScreen-7142120.0/
>>>>
>>>> The fix is fairly simple: use NSScreen -frame instead of -visibleFrame.
>>>> In this case the splash screen is positioned in the geometrical center
>>>> of the screen. Visually this looks less pleasant (we may want to file an
>>>> RFE in the future), but makes tests happy which is what we need right now.
>>>
>>> So what exactly do the tests expect? Does the test calculates the expected 
>>> splashscreen position and compares to the value of SplashScreen.getBounds()? 
>>> Does the latter method returns an incorrect value?
>>>
>>> What I see in JavaDoc is just: "The window is positioned at the center of 
>>> the screen." It's unclear if the center of the screen should or should not 
>>> include screen insets.
>>
>> The test uses a 100x100 pixels image as a splash screen image. It then calls 
>> the GraphicsDevice.getDisplayMode().getWidth/Height() methods and expects to 
>> find the splash screen in the geometrical center of the screen (using 
>> SplashScreen.getBounds()). I.e. the screen insets are ignored.
>>
>> Given that the tests pass on Windows, Linux, and Solaris, it makes sense to 
>> implement the same behavior on Mac OS X as well.
>>
>> -- 
>> best regards,
>> Anthony
>>
>>>
>>> Thanks,
>>>
>>> Artem
>>>
>>>> All the failing tests now pass well with this fix applied.
>>>>
>>>> -- 
>>>> best regards,
>>>> Anthony
>
>