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

[Mike Swingler]

My suggestion is to not show a dialog at all (particularly for a common situation like network disconnect, which should happen all the time on a portable). Instead, if you could simply augment the UI of the application (perhaps disable some controls, or show a prominent indicator), you could evade the problem and create a more pleasant experience that doesn't disrupt the users workflow by design.

AppKit has separated out the concepts of how windows can have "key focus", can be "main" (the darker appearance with the thicker shadow), and be in different stacking order as independent concepts. Usually when you are typing along and a dialog comes up from another app, it may be atop other windows, but it hasn't necessarily stolen key focus. Utility windows can also be on top of "main" windows but key focus has to be explicitly granted by clicking into them.

Java does not distinguish between key and main (it only has "focused"), and only has the rough concept of "always on top", which doesn't mesh well with the app-level ordering of Mac OS X. It's unfortunate, but AWT/Swing does not have suitable primitives to give developers so they can do the right thing. Of the primitives that do exist with regards to parent/child ordering, there are some key decisions that have to run counter to how Mac OS X convention works to pass the TCK, and prevent us from doing the most intuitive thing with respect to spaces and the full screen experience.

On Java SE 6, we do try to prevent Java apps from jacking control from other applications, however if you are already in the app, and it shows a dialog, the mandatory Java behavior to be able to focus all controls means that the OK button can be dismissed with both space and return (whereas in native Cocoa apps, it would only be dismissible with return, unless you turned on "focus all controls" in the keyboard preference pane).

The combination of all of these factors leads to an subconsciously irritating experience which is often impossible to communicate to others who do not live on Mac OS X, and is unfortunately irreconcilable with the current API and TCK requirements. My best advice would be to evade the problems where you can in your apps UI design, and just make the whole thing a non-issue.

Regards,
Mike Swingler
Apple Inc.

On Feb 7, 2012, at 8:23 AM, Gregg Wonderly wrote:

> 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
>> 
>> 
>