Re: AWT Dev [9] Review Request: JDK-8036757 [macosx] Space menu accelerator not rendered correctly
Back in 2009 we made the same fix for Java SE 6. I'm not sure why that change never made it's way to our contribution to OpenJDK, but it's definitely correct to use the ' ' space character. I also suspect that kMenuSpaceGlyph is from Carbon, which is probably why it was commented out in the OpenJDK commit. Regards, Mike Swingler Apple Inc. On Mar 6, 2014, at 2:07 AM, Anthony Petrov anthony.pet...@oracle.com wrote: Hi Petr, The fix looks good technically. However, I'm not sure if allowing apps to use the Cmd-Space shortcut is a good idea because by default this key combination is used to either switch between keyboard layouts, or activate the SpotLight. So I think this line has been commented out because of Human Interface Guidelines for OS X. I'm not 100% convinced we should change that. Are there other opinions? Mike, what do you think? -- best regards, Anthony On 3/6/2014 1:00 PM, Petr Pchelko wrote: Hello, AWT Team. Please review a one-liner for: https://bugs.openjdk.java.net/browse/JDK-8036757 The fix is available at: http://cr.openjdk.java.net/~pchelko/9/8036757/webrev/ I supple this line was commented out because the code is not compilable with it) We should return a space character, it will be replaced with a proper ‘Space’ string internally by Cocoa. In case the app is bundled the string would even be localized. In non-bundled apps native localization does not work, but we can do nothing about it. With best regards. Petr.
Re: AWT Dev Embedding native widgets into AWT Canvas on Mac - NSView / CALayer pb in JDK1.7
On Dec 20, 2013, at 6:41 AM, Christophe Cornu christophe.co...@gmail.com wrote: Hello: Since JDK1.7, Canvas is no longer backed up by an NSView. This broke a few projects, e.g. https://bugs.eclipse.org/bugs/show_bug.cgi?id=418245. It's no longer possible to embed inside AWT things like SWT widgets, Apple WebView component (which extends NSView). What do the AWT committers think going forward? Will it be possible to have an internal Canvas class that would be backed up by NSView, to be used by embedders? Or should we give up the idea of plugging in native widgets into AWT through NSView and treat CALayer as the way forward? The crux of the problem has to do with the applet embedding case, where the underlying primitive provided by the browser is a CALayer, and there is no underlying NSView, and all events are synthetic and re-dispatched through the NPAPI. This enables the sandboxing and cross process rendering that applets require. The entirety of the Java 2D graphics stack in Java 7 now renders using pure OpenGL onto a single canvas, and there is no (significant) NSView or CALayer hierarchy. To re-introduce an NSView hierarchy, you'd have to split the OpenGL rendering layers between the components that should be atop each JAWT NSView and the components that should be below. The task is not without complexity, but the payoff would be quite significant with respect to event dispatch, and re-enabling all the old embedding designs. If you'd like to take this on, I'm sure many people would appreciate it, but I want you to be aware of the full complexity of the task. There certainly have been no volunteers thus far. Regards, Mike Swingler Apple Inc.
Re: AWT Dev [OpenJDK 2D-Dev] [8] Review request for 8011059 [macosx] Make JDK demos look perfect on retina displays
On Dec 3, 2013, at 10:10 AM, Jim Graham james.gra...@oracle.com wrote: Hi Mike, One more question about @2x handling on MacOS. Clearly, in the simple case of someone loading an ordinary foo.png and painting it on a retina display without doing anything special with the transform, it will be scaled up by 2x to retain proper size. Also, clearly, if a f...@2x.png file exists, it will be loaded automatically and found to be twice as large and displayed with no scaling so that it is the same size. But, what if in the first step they manually specified the image file name as f...@2x.png (and assuming there is no foo@2...@2x.png)? Will it display with its pixels scaled up to double sized because it was the direct image that they specified? Yes, explicitly asking for foo@2x cause the search machinery to look for f...@2x.png and foo@2...@2x.png. Or, does the system recognize that it came from a file named @2x and assume that it is a double-screen-resolution image and paint it the same way it would have done if it was implicitly loaded as the higher resolution variant of foo.png? No. Images reps loaded with the @2x suffix are not special — they are just an additional representation of the same named image, and could vary unpredictable in dimensions, bit depth, and color space. We simply prefer that they not. :-) Let me spell out the scenarios: Scenario 1: - app is retina-enabled - app has WxH foo.png media (and no @2x versions) - app loads image from foo.png - app displays image with standard default scaling on a retina screen = result is image takes up 2W x 2H pixels on the retina screen Scenario 2: - app is retina-enabled - app has WxH foo.png media - app also has 2W x 2H f...@2x.png media - app loads image from foo.png - app displays image with standard default scaling on a retina screen = result is system also loads f...@2x.png and displays it with 2W x 2H retina pixels on the retina screen - the same physical size as in the previous example Scenario 3: - app is retina-enabled - app has WxH foo.png media - app also has 2W x 2H f...@2x.png media - app loads image from f...@2x.png rather than foo.png - app displays image with standard default scaling on a retina screen = result is ??? = I'm guessing that it gets drawn twice the size as Scenario's 1 and 2 because it is no longer relative to the WxH base image? Scenario 4: same as Scenario 3, but foo.png doesn't exist, f...@2x.png is the only version found in the media for the app = result is ??? = I'm guessing the result is the same as Scenario 3 Also, the convention is for the @2x image to be twice the pixel size of the regular image, but what if it isn't? Is it always drawn at a 0.5x relative scale because of the implication of the @2x file name, or will it be dynamically sized for basew/@2xw, baseh/@2xh which just usually works out to 0.5x if the author followed conventions? ...jim @2x in the file name is just a hack to add more representations to images that are not already multi-rep (.png vs. .tiff and .icns). The actual dimensions of the image dictate when/how it gets used at runtime. I believe the search for @2x variants is only performed if the original image rep is not sufficient to fully fill the rect of pixels in the destination. Regards, Mike Swingler Apple Inc.
Re: AWT Dev [8] Review request for 8011059 [macosx] Make JDK demos look perfect on retina displays
On Nov 12, 2013, at 7:10 PM, Jim Graham james.gra...@oracle.com wrote: So, then, it sounds like on the Mac the default heuristic should be to take the transform into account and choose @2x based on that. We don't yet know if that matches the default Windows 8 heuristics, but we only have 1 platform that has this enabled so far. One last question (OK 2) for Mike - I want to be sure that we get the algorithm right, you said if the backing store would be the same size or smaller than the @1x which implies that the code in the fix if (w = imgw h = imgh) regular : @2x matches the heuristics in Cocoa? (i.e. and = are the correct comparison and logic?) This check seems correct to me. If either the w or h of the destination rect needs more pixels than is available from w or h of a given representation, the logic should choose the next representation, or fall back to scaling up the available pixels in the largest representation (insert caveats about bit depth, color space, and vector drawing resources like PDF). And question #2, if they are running on a display with pixel scale of 1.0, does the @2x get chosen when they scale up? Or do the @2x media only even get considered on pixel scaled displays? In the demo that I sent you — the @2x gets chosen when displaying a scaled up image on a non-Retina display. The @2x is nothing special; it's just another representation. This is how NSImage has always worked long before Retina, since Mac OS X 10.0, AFAIK. Given that, I'd recommend: - Add the DEFAULT setting for the SunHint which will basically say do as Mac does when on a Mac (and eventually as Win8 does while on Win8, etc.) - the current fix has the choice in the macosx code, which is good - the current API provides the scaled dimensions, which is good for the mac code, but we may need to make more data available once we learn how other platforms solve this problem - we may want to beef up the hints later with choose based on Screen vs choose based on pixel size, but for now this API is sun.* private so lets just leave it with ON/OFF/DEFAULT. - Hopefully the answers to the above 2 questions for Mike won't be surprising... ...jim I hope I haven't surprised anyone. :-) Regards, Mike Swingler Apple Inc. On 11/12/13 6:46 PM, Mike Swingler wrote: The story is a little more complicated: NSImage always picks the best representation based on the computed size of the backing pixel rect taking all graphics transforms into account. For icons, which usually have dozens of representations, there isn't a single @2x representation. This means that by switching screens, an icon can flip from a cartoonish 16x16 rep to a photo-realistic 128x128 scaled down to 32x32 if those are the only reps available. The multi-rep support in NSImage can also defer to a PDF representation if available when it can't find an exact dimension and bit-depth match for raster representations. This does mean that an icon with 12 or so representations will visually glitch when smooth scaled as bits of detail come and go...but in the general case, most images tend to only have 2 reps and developers don't animate between them. So to be explicit: no, NSImage Cocoa drawing will not choose the @2x version if the transform causes the rect in the pixel backing store to be the same size or smaller than the @1x. I'll privately send along a little app that demonstrates this. Regards, Mike Swingler Apple Inc. On Nov 12, 2013, at 5:52 PM, Jim Graham james.gra...@oracle.com wrote: Hi Mike, Just to confirm and be explicit, the Mac will choose the @2x version of an image if that call returns 2.0 even if the user is rendering with a transform that scales by .001? ...jim On 11/12/2013 5:48 PM, Mike Swingler wrote: On Nov 12, 2013, at 11:43 AM, Jim Graham james.gra...@oracle.com wrote: - It looks like the transform is used in SG2D to decide if the hiDPI image should be used. I'm not familiar with the Mac's native use of @2x, but I thought that they hinged the decision off of the retina scale of the display, not off of the current transform. That way, if you scale down an icon it doesn't change its look when it reaches .5x scale (or .75x depending on the cutoff). Personally, I think it is better to not use the transform to keep animations smooth, but I'm not sure what Apple did. The -[NSWindow backingScaleFactor] is the basic primitive that other forms of coordinate translation key off of. Keep in mind that this value will dynamically change as the window moves from display to display. Regards, Mike Swingler Apple Inc.
Re: AWT Dev [8] Review request for 8011059 [macosx] Make JDK demos look perfect on retina displays
On Nov 12, 2013, at 11:43 AM, Jim Graham james.gra...@oracle.com wrote: - It looks like the transform is used in SG2D to decide if the hiDPI image should be used. I'm not familiar with the Mac's native use of @2x, but I thought that they hinged the decision off of the retina scale of the display, not off of the current transform. That way, if you scale down an icon it doesn't change its look when it reaches .5x scale (or .75x depending on the cutoff). Personally, I think it is better to not use the transform to keep animations smooth, but I'm not sure what Apple did. The -[NSWindow backingScaleFactor] is the basic primitive that other forms of coordinate translation key off of. Keep in mind that this value will dynamically change as the window moves from display to display. Regards, Mike Swingler Apple Inc.
Re: AWT Dev com.apple.eawt.Application.setOpenURIHandler does not deliver initial launch URI
This looks reasonable to me. Did you test the fix using the leaks to
determine that the descriptors or the block itself were not over-retained?
Regards,
Mike Swingler
Apple Inc.
On May 27, 2013, at 6:53 AM, Anthony Petrov anthony.pet...@oracle.com wrote:
Thanks for testing, James. I'm fine with the fix then.
Note that we need at least one more review from a reviewer on this mailing
list before we can push your fix to the repository.
Anyone?
--
best regards,
Anthony
On 05/24/13 22:39, James Tomson wrote:
Hi Anthony,
Thanks for taking a look. To answer your questions, the
application:openFiles and application:printFiles methods should not need
similar special treatment - the passed instances should be getting
implicitly retained and released by the block from my understanding, and
can be queued for later processing without a problem. Testing locally
with those handlers, the OpenFilesEvent and PrintFilesEvent events on
the java-side are delivered without issue when the app is launched from
an open file or print file event from the Finder.
The issue with the passed NSAppleEventDescriptors is that while the
objects are properly retained and released by the block, the Apple Event
Handling system seems to be marking the instance's internal state as
otherwise invalid/expired even though the instance itself is still
retained. I'm unable to find any specific documentation or discussion
about the lifecycle of these event descriptor objects though.
-James
On Fri, May 24, 2013 at 12:13 PM, Anthony Petrov
anthony.pet...@oracle.com mailto:anthony.pet...@oracle.com wrote:
Hi James,
I like your patch.
Do you know if other handlers are affected by a similar issue? In
particular, the application:openFiles and application:printFiles
also take references to NSObjects as their arguments. Could you
please test if these handlers are affected or not?
--
best regards,
Anthony
On 05/23/2013 10:56 PM, James Tomson wrote:
Hi - this issue was originally discussed on the jdk7u-dev list here:
http://mail.openjdk.java.net/__pipermail/jdk7u-dev/2013-May/__006446.html
http://mail.openjdk.java.net/pipermail/jdk7u-dev/2013-May/006446.html
Additionally a report should be available soon in the bug
database as
(JDK-8015302)
http://bugs.sun.com/__bugdatabase/view_bug.do?bug___id=8015302
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8015302
To summarize, a bundled mac application which registers custom url
schemes via the CFBundleURLSchemes entry in its Info.plist, and
listens
for uri events using
com.apple.eawt.Application.__setOpenURIHandler, will
not receive the URI used to launch the application.
Once the application is running however, subsequent openURI
events will
be delivered without issue. The problem only manifests with the
URI is
used to launch the App initially.
When the app is opened via URI, the following appears in the
system log:
--
JavaAppLauncher[74278]: -[NSAppleEventDescriptor
paramDescriptorForKeyword:] called on invalid NSAppleEventDescriptor
--
It appears that since the QueueingApplicationDelegate is only
keeping
references to those descriptor objects instead of making deep
copies of
them,
the event descriptor for the initial URI that launches the app is
invalidated by the time the app actually gets around to
processing it.
The following patch (same for both jdk8 and jdk7u sources) seems to
resolve the issue:
diff --git
a/src/macosx/native/sun/__osxapp/__QueuingApplicationDelegate.m
b/src/macosx/native/sun/__osxapp/__QueuingApplicationDelegate.m
--- a/src/macosx/native/sun/__osxapp/__QueuingApplicationDelegate.m
+++ b/src/macosx/native/sun/__osxapp/__QueuingApplicationDelegate.m
@@ -110,8 +110,14 @@
- (void)_handleOpenURLEvent:(__NSAppleEventDescriptor
*)openURLEvent
withReplyEvent:(__NSAppleEventDescriptor *)replyEvent
{
+// Make an explicit copy of the passed events as they may be
invalidated by the time they're processed
+NSAppleEventDescriptor *openURLEventCopy = [openURLEvent copy];
+NSAppleEventDescriptor *replyEventCopy = [replyEvent copy];
+
[self.queue addObject:[^(){
-[self.realDelegate _handleOpenURLEvent:__openURLEvent
withReplyEvent:replyEvent];
+[self.realDelegate _handleOpenURLEvent:__openURLEventCopy
withReplyEvent:replyEventCopy]__;
+[openURLEventCopy release];
+[replyEventCopy release];
} copy
Re: AWT Dev [8] Request for review: 8008660 : Failure in 2D Queue Flusher thread on Mac
On Feb 22, 2013, at 10:05 AM, Sergey Bylokhov sergey.bylok...@oracle.com wrote: Hello, Please review the fix for jdk 8. Fix will be ported to jdk7 as well. There is a few problems: 1 To eliminate the crash we should check that the system return correct CGLConfigInfofrom in CGLGraphicsConfig.getConfig(). (see http://bugs.sun.com/view_bug.do?bug_id=6755274) 2 Requested opengl attributes are too strict, so we cannot fail-back to the software renderer. Next attrs were removed: NSOpenGLPFANoRecovery, - if an accelerated renderer fails due to lack of resources, OpenGL automatically switches to another renderer. NSOpenGLPFAAccelerated, - accelerated renderers are still preferred. NSOpenGLPFAFullScreen, - we don't use this functionality. Also in this code we try to mix CoreGraphics display id and Screen index. Currently we never use screen index so all related code was removed/renamed to be more obvious. Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8008660 Webrev can be found at: http://cr.openjdk.java.net/~serb/8008660/webrev.00 This looks good. I like the simplification. Regards, Mike Swingler Apple Inc.
Re: AWT Dev NSOpenGLLayer animation issue under VNC
On Feb 1, 2013, at 7:37 AM, Alexander Scherbatiy alexandr.scherba...@oracle.com wrote: Hello Mike, There is the issue 8005668 security control panel got greyed out when access Mac machine remotely using VNC http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8005668 After a little investigation we have found that an animation does not work for the NSOpenGLLayer if a user uses VNC connection and the MAC OS X does not have connected monitors. Here are steps to reproduce which use only Cocoa application: - Connect to an Mac OS X with VNC - Detach all monitors from the Mac OS X (I used a Mac mini) - Run the code below The animation does not work The output shows that the drawInCGLContext method has been invoked only once or twice: -- 2013-02-01 19:21:27.488 OpenGLLayerSample[1731:707] invalid drawable 2013-02-01 19:21:27.489 OpenGLLayerSample[1731:707] drawInCGLContext 2013-02-01 19:21:27.513 OpenGLLayerSample[1731:707] drawInCGLContext -- Connection a monitor to the Mac OS X makes the animation work. It seems that it can have a relation to the issue 8005668 so the first time there is nothing to draw and next time nothing is drawn on a Java app. Is it a known issue and could it have a workaround? This does appear to be a bug in the OS - you should see some an animation when you are screen-shared into the machine. Please file a bug at http://bugreporter.apple.com, and let me know what the bug ID is so I can ensure that it gets to the correct team. Thanks, Mike Swingler Apple Inc.
Re: AWT Dev [8] Review request for 8007006 : [macosx] Closing subwindow loses main window menus
Honestly, I have no idea why that was commented out. Perhaps we were debugging the support for the default menu stuff in com.apple.eawt.Application.setDefaultMenuBar(JMenuBar)? It was so long ago I honestly have no idea. Regards, Mike Swingler Apple Inc. On Jan 29, 2013, at 9:52 AM, Leonid Romanov leonid.roma...@oracle.com wrote: Looks like it was Mike Swingler who committed this, already commented code, to the old repo. Adding him to CC. On Jan 29, 2013, at 8:06 PM, Anthony Petrov anthony.pet...@oracle.com wrote: Hi Leonid, I see that the lines were commented out since the initial push of the MacOSX port code to the JDK repository. Could you please clone the old workspace (when we worked in a separate set of repositories) and investigate why were the lines commented out in the first place? PS. The fix looks fine and correct. But I'd like to make sure we don't remove a workaround for some other problem with this fix. -- best regards, Anthony On 1/29/2013 19:57, Leonid Romanov wrote: Hi, Please review a fix for 8007006 : [macosx] Closing subwindow loses main window menus. The problem manifests itself when the global menu bar is used and we change menu for an inactive window. In this case current global menu gets replaced by the menu we set for the inactive window (or disappear completely, if the inactive window menu was removed). webrev: http://cr.openjdk.java.net/~leonidr/8007006/webrev.00/ Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8007006 Leonid.
Re: AWT Dev [OpenJDK 2D-Dev] Fwd: Need reviewers: more predictable binaries
My strong suspicion is that the JDK Makefiles only use CFLAGS, not CPPFLAGS for .m files. CPPFLAGS should be used for .mm files (but those should be really rare). Regards, Mike Swingler Apple Inc. On Sep 6, 2012, at 11:35 AM, Scott Kovatch scott.kova...@oracle.com wrote: I feel like I should be able to find the answer to this, but does Objective-C use CPPFLAGS? I can't tell if these changes would apply to .m or .mm files. It certainly appears to be the intent of the change, since a number of .m files in the AWT were changed to use THIS_FILE. -- Scott K. On Sep 6, 2012, at 9:30 AM, Kelly O'Hair kelly.oh...@oracle.com wrote: Just FYI... these build changes do touch sources in various teams, please let me know if you have issues with these changes. -kto Begin forwarded message: From: Kelly O'Hair kelly.oh...@oracle.com Subject: Need reviewers: more predictable binaries Date: September 5, 2012 9:08:53 PM PDT To: build-...@openjdk.java.net build-dev build-...@openjdk.java.net Need a reviewer for this change. http://cr.openjdk.java.net/~ohair/openjdk8/jdk8-this-file/webrev/ It does change source, but it's effectively a build change. The goal here is to try and create more predictable binary files and remove the possibility that a full source path (via __FILE__) gets baked into the shared libraries or executables shipped. So two changes: * sort the .o files during links so they are always provided to the linker in the same order. * replace use of __FILE__ to the macro THIS_FILE with just the basename of the source file being compiled The __FILE__ issue is that it has an implementation defined string literal value, depending on the compiler and the filename supplied on the compile line. By changing to the new THIS_FILE macro, the object files will always have a consistent string literal in them, making it easier to compare binaries between builds. Something we have never been able to do in the past. Granted it's just the basename for the file, but should be enough. The tricky part is that __FILE__ only gets evaluated when it is used. In normal C code, it will appear in macros but it only will get evaluated in the source file being compiled. It is rare that macros using __FILE__ will get expanded in include files and I detected this not happening in the jdk source at all. -kto
Re: AWT Dev [8] Review request for 7171045 [macosx] There are no enter or exit events reported against 8b39 for MouseEventsDuringDrag.
I noticed that, NSWindow's windowNumber is NSInteger, which is 32 bits wide on 32-bit and 64 bits wide on 64-bit. Chopping that to a simple 32 bit int is probably not what you intended to do. Also, have you considered simply calling -[NSWindow setAcceptsMouseMovedEvents:YES] in -[AWTView initWithRect:], and then removing the calls that flip it on and off in -[AWTView mouseEntered:] and -[AWTView mouseExited]? This would also require a change in Java_sun_lwawt_macosx_CPlatformWindow_nativeSetNSWindowBounds(), which has a comment that states it only turns on mouse moved events if the window is currently under the mouse. I would think that AppKit should be more than happy to send you mouse-over/enter/exited events as long as you say you want them. Was this approach tried and didn't work for some reason? Regards, Mike Swingler Apple Inc. On Aug 7, 2012, at 4:33 AM, Sergey Bylokhov sergey.bylok...@oracle.com wrote: Hi, Alexander. Probably all this stuff can be simplified? Can you try to change TrackingRect to TrackingArea with appropriate flags like NSTrackingEnabledDuringMouseDrag etc. 07.08.2012 15:17, Alexander Scherbatiy wrote: bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7171045 webrev: http://cr.openjdk.java.net/~alexsch/7171045/webrev.01/ This is a regression after the fix 7154048 [macosx] At least drag twice, the toolbar can be dragged to the left side. In the case where a toolbar is created under a mouse and it is dragged over the initial window the mouse enter/exit events should not be generated for the components which are under the toolbar. The current fix is supposed to solve this regression and also to fix generation of mouse enter/exit events for all cases where a mouse is dragged from one window to another or a new window is created under a mouse (like it is implemented for toolbar). Let's see the following cases 1) Mouse is dragged from a window and back to the same window. The Mac OS X system generates a mouse exit event only the first time when a mouse is dragged from a window and does not generate mouse enter/exit events next times during one drag trace. 2) Mouse is dragged from one window to another. The Mac OS X system does not generate mouse enter/exit events for the second window. 3) Mouse is dragged from one window to another and released. In this case the Mac OS X system generates mouse enter event for the second window only after releasing the mouse. 4) Clicking on window creates a new window after that the new window is dragged (toolbar dragging). However the Java system generates mouse enter/exit events each time when a mouse is dragged over any window. To fix this the following methods are introduced: - Get topmost window under mouse - Synthesize mouse enter/exit events for all windows The dispatchMouseEvent method from the LWWindowPeer class is handled previous and next components and is able to generate mouse enter/exit events for them. However the the AWTView native class contains isMouseOver flag which value becomes inconsistent if we do not updated it. Because of this the fix generates the mouse enter/exit window events on the native side. Generating mouse enter/exit events always should be in order where mouse exit events are generated before the mouse enter events. The synthesizeMouseEnteredExitedEventsForAllWindows method tries to generate mouse enter/exit events for all windows during mouse drag or window creation/window bounds changing. However only those windows which isMouseOver flag is differ from the isTopMostWindowUnderMouse state are affected. This method also tries to generate both mouse enter and exit event for the same window but only one of them can be applicable because the isTopMostWindowUnderMouse state is not changed for these calls. So the window enter/exit events now are always generated from the native system and component enter/exit events are generated in the LWWindowPeer class. LWWindowPeer class now uses three links to components: current, last and topmostUnderMouse. All of them are necessary because in case when a mouse is dragged from one window to another the current component receives drag events and last and topmostUnderMouse links handle components mouse exit/enter events on the second window. Thanks, Alexandr. -- Best regards, Sergey.
Re: AWT Dev [7u6] Review request for 7181027: [macosx] Unable to use headless mode
On Jul 13, 2012, at 5:40 PM, David Holmes wrote: On 14/07/2012 12:23 AM, Mike Swingler wrote: On Jul 13, 2012, at 6:22 AM, Anthony Petrovanthony.pet...@oracle.com wrote: On 7/13/2012 5:09 PM, David Holmes wrote: On 13/07/2012 10:58 PM, Anthony Petrov wrote: I dug into the code history a little. The following Mike's changeset is to blame for using HToolkit in headless mode on the Mac: http://hg.openjdk.java.net/macosx-port/macosx-port/jdk/rev/67591b2326bf I've looked through the LWCToolkit.m which implements native methods specific to the real, headful Mac toolkit, and actually all of the code seems to be related to headful behavior only. Note that in the headless mode the awt_LoadLibrary.c will still load the correct lwawt dynamic native library, so all the necessary steps to initialize the app from Mac OS X perspective will be performed anyway, and all the native methods required by CFontManager and other C* classes will be available also. So basically I don't really see a problem with using the HToolkit class for headless mode on the Mac. Note that Toolkit.getDefaultToolkit() will wrap the real toolkit instance into a HeadlessToolkit class anyway, so code that relies on instanceof checks against a toolkit instance should not be affected by this choice in any way. David, do you see any specific issues with using HToolkit on a desktop (Mac) system? No. I'm just wary of it. I'm curious what would have been done if this HToolkit class had not existed? Either it would have been introduced, or the LWCToolkit/LWToolkit classes would have been made more headless-aware, so to speak. I think Mike could shed some light on his decision. I was looking for a way to ensure that once the choice to be headless was made, there would be no way to undo it. We've had problems in Java SE 6 and prior where the old CToolkit was mostly headless, but could still try to make contact to the window server for somethings (edge cases in fonts, IIRC). This would mostly work for a while under an SSH session, but would die some hours later after Mach bootstrap session expired, and lead to diagnosing some fairly frustrating bugs. With HToolkit, the boot comes down immediately about what you can and cannot do - and the implementation looked simple enough, I didn't see much risk. It was there, it worked, I went with it. Anyway, to conclude the reviewing thread, given that we don't (currently) see any problems with using HToolkit on the Mac, and the fact that it's already been used in headless mode on the Mac for a while, I'm fine with the fix proposed by Leonid. I personally don't see why HToolkit couldn't be used unilaterally for headless mode on all platforms. Wouldn't any breakage show an improper layering violation that should not have been allowed to occur in the first place? It was introduced for platforms with absolutely zero graphics related capabilities - not even libraries installed let alone hardware. The pre-existing headless toolkits still required some of this support for, as I recall, printing/font related things - which must still be supported even in headless mode. As long as this is passing the full set of TCK/JCK tests then it is usable. In OS X, it is unsafe to communicate with any Cocoa code in a headless/server environment, so this is actually a good match for our usage. Any font usage or printing done in this mode would have to fall back to only font files and CUPS sockets, and not rely on the CoreText/CoreGraphics API. Trying to add font or printing in a server context might be a reason to sub-class or extend HToolkit - but I imagine some of that implementation would be common with the XToolkit, and that would be an interesting design discussion how to tease all that apart and recombine it in a modular way that would allow CToolkit to delegate to it without introducing a dependency on X11. Regards, Mike Swingler Apple Inc.
Re: AWT Dev [7u6] Review request for 7181027: [macosx] Unable to use headless mode
On Jul 13, 2012, at 6:22 AM, Anthony Petrov anthony.pet...@oracle.com wrote: On 7/13/2012 5:09 PM, David Holmes wrote: On 13/07/2012 10:58 PM, Anthony Petrov wrote: I dug into the code history a little. The following Mike's changeset is to blame for using HToolkit in headless mode on the Mac: http://hg.openjdk.java.net/macosx-port/macosx-port/jdk/rev/67591b2326bf I've looked through the LWCToolkit.m which implements native methods specific to the real, headful Mac toolkit, and actually all of the code seems to be related to headful behavior only. Note that in the headless mode the awt_LoadLibrary.c will still load the correct lwawt dynamic native library, so all the necessary steps to initialize the app from Mac OS X perspective will be performed anyway, and all the native methods required by CFontManager and other C* classes will be available also. So basically I don't really see a problem with using the HToolkit class for headless mode on the Mac. Note that Toolkit.getDefaultToolkit() will wrap the real toolkit instance into a HeadlessToolkit class anyway, so code that relies on instanceof checks against a toolkit instance should not be affected by this choice in any way. David, do you see any specific issues with using HToolkit on a desktop (Mac) system? No. I'm just wary of it. I'm curious what would have been done if this HToolkit class had not existed? Either it would have been introduced, or the LWCToolkit/LWToolkit classes would have been made more headless-aware, so to speak. I think Mike could shed some light on his decision. I was looking for a way to ensure that once the choice to be headless was made, there would be no way to undo it. We've had problems in Java SE 6 and prior where the old CToolkit was mostly headless, but could still try to make contact to the window server for somethings (edge cases in fonts, IIRC). This would mostly work for a while under an SSH session, but would die some hours later after Mach bootstrap session expired, and lead to diagnosing some fairly frustrating bugs. With HToolkit, the boot comes down immediately about what you can and cannot do - and the implementation looked simple enough, I didn't see much risk. It was there, it worked, I went with it. Anyway, to conclude the reviewing thread, given that we don't (currently) see any problems with using HToolkit on the Mac, and the fact that it's already been used in headless mode on the Mac for a while, I'm fine with the fix proposed by Leonid. I personally don't see why HToolkit couldn't be used unilaterally for headless mode on all platforms. Wouldn't any breakage show an improper layering violation that should not have been allowed to occur in the first place? Regards, Mike Swingler Apple Inc.
Re: AWT Dev [8] Review request for: 7172722: Latest jdk7u from OSX broke universal build
Looks great. Mike Swingler Apple Inc. On Jun 4, 2012, at 7:48 AM, Anthony Petrov wrote: AWT/MacOSX-port-dev teams, Could I get a review for this one-line fix please? -- best regards, Anthony On 06/01/12 12:47, Henri Gomez wrote: Tested and it works for me. I just produced jdk7u b12 with it : http://openjdk-osx-build.googlecode.com/files/OpenJDK-OSX-1.7-universal-u-jdk-jdk7u6-b12-20120601.dmg Cheers 2012/5/30 Anthony Petrovanthony.pet...@oracle.com: Hello, Please review a fix for http://bugs.sun.com/view_bug.do?bug_id=7172722 at: http://cr.openjdk.java.net/~anthony/8-33-MacUniversalBuild-7172722.0/ I've simplified the fix comparing to original Henri's proposal [1] to follow the same pattern as we use with other properties: we simply give the corresponding class fields the same names as to the properties themselves. Henri: please verify if the new patch works for you. [1] http://mail.openjdk.java.net/pipermail/jdk7u-dev/2012-May/003191.html -- best regards, Anthony
Re: AWT Dev [7u6] Review request for 7168062: [macosx] Java processes on Mac should use Oracle Java branded icons
On May 24, 2012, at 7:49 PM, Scott Kovatch wrote: OpenJDK (IMO) shouldn't rely on an icon in a framework that could disappear in the next year or two, so it should use its own icon. The AWT will need to change for that to happen. If Apple would like to donate this icon I think it would be great, and would solve that problem nicely. It's then up to Leonid to decide how to best use it. Just my 2¢ here: * It is not accurate to imply that any Apple framework or resource therein is going to go away in the next year or two. * The Apple GenericApp.icns will be around as long as JavaRuntimeSupport and JavaNativeFoundation. * The Apple GenericApp.icns will stay as is (it will not be up-res'd or improved). The GA'd versions of 7u4 have effectively locked the filesystem location of this icon in stone for their supported lifetimes, in addition to all of Apple's Java SE 6 versions. I wouldn't suggest using the Apple icon if there is better or more accurate iconography available, but there is no risk in having a runtime dependency on it, as there is already today. Regards, Mike Swingler Apple Inc.
Re: AWT Dev [8] Review request for 7124337: [macosx] FileDialog fails to select multiple files
On May 14, 2012, at 7:30 AM, Dmitry Cherepanov wrote: This is a direct forward port (including a minor change for 7147066) of the fix to jdk8. Bug: http://bugs.sun.com/view_bug.do?bug_id=7124337 Webrev: http://cr.openjdk.java.net/~dcherepanov/7124337/8/webrev.0/ Looks good, Mike Swingler Apple Inc.
Re: AWT Dev [7u6] Review request for 7149062: [macosx] dock menu don't show available frames
On May 12, 2012, at 5:20 AM, Anthony Petrov wrote: Hello, This is almost a direct back-port of the same fix from JDK 8. Bug: http://bugs.sun.com/view_bug.do?bug_id=7149062 Fix: http://cr.openjdk.java.net/~anthony/7u6-9-windowListInDockMenu-7149062.0/ Looks good, Mike Swingler Apple Inc.
Re: AWT Dev [8] Review request for 7149062: [macosx] dock menu don't show available frames
Looks good to me. Cheers, Mike Swingler Apple Inc. On May 5, 2012, at 5:57 AM, Anthony Petrov wrote: Thanks for reviewing that. Your suggestion sounds reasonable, so I've published a new webrev at: http://cr.openjdk.java.net/~anthony/8-26-windowListInDockMenu-7149062.2/ -- best regards, Anthony On 5/5/2012 1:50 AM, Mike Swingler wrote: Overall, this looks good, but my one suggestion would be to NOT break out AWTWindow_Normal and AWTWindow_Panel into their own files, but instead to put them side-by-side in the AWTWindow implementation. You could possibly share part of their implementations in a macro to enforce that they don't fall out of sync with each other over time, but that might be overkill - though I think keeping them in the same file will be important for people to see both at the same time. Regards, Mike Swingler Apple Inc. On May 4, 2012, at 9:09 AM, Anthony Petrov wrote: Thanks for the review. -- best regards, Anthony On 5/4/2012 8:07 PM, Scott Kovatch wrote: On May 4, 2012, at 4:43 AM, Anthony Petrov wrote: I've investigated that, but it looks like a category (or an extension) requires a class name to add methods to. It's impossible to define an anonymous category and then apply it to two different classes. However, for the sake of this fix we do need to have two distinct classes: one inheriting from NSWindow, and another - from NSPanel. I can't find anything Obj-C-wise that could help eliminate the code replication here. Well, we could extract it into a separate file and #include it within the corresponding @implementation sections. But given the really small size of the replicated code this would look a bit weird in my opinion. No problem -- it was more a random thought than a concrete suggestion. I doubt we will be changing much in either file over time. So I re-generated the webrev w/o the UTILITY thing mentioned above. The final webrev is at: http://cr.openjdk.java.net/~anthony/8-26-windowListInDockMenu-7149062.1/ Looks OK to push that? Looks good to me. -- Scott K.
Re: AWT Dev [7u6] Review request for 7159266: [macosx] ApplicationDelegate should not be set in the headless mode
On Apr 5, 2012, at 8:01 AM, Anthony Petrov wrote: Hello, Please review a fix for http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7159266 at: http://cr.openjdk.java.net/~anthony/7u6-4-fxHang-7159266.0/ With this fix we avoid setting an application delegate when AWT is started in the headless mode. This prevents a hang when another GUI toolkit (e.g. JavaFX) is already running in the same Java process. This would logically mean that you won't get eAWT events (file open, quit, etc) while started in this mode. Does this impact SWT as well? Regards, Mike Swingler Apple Inc.
Re: AWT Dev [7u6] Review request for 7159266: [macosx] ApplicationDelegate should not be set in the headless mode
How would an SWT developer accept new open document file double-clicks, or listen for sleep/wake events? AFAIK, eAWT is the only aperture that handles that right now. Regards, Mike Swingler Apple Inc. On Apr 5, 2012, at 1:11 PM, steve.x.northo...@oracle.com wrote: Hi all, Headless mode works fine for SWT. SWT doesn't use eAWT to do Quit etc. Instead, it uses the appropriate native cocoa calls. Steve On 05/04/2012 11:23 AM, Anthony Petrov wrote: On 04/05/12 19:07, Mike Swingler wrote: Please review a fix for http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7159266 at: http://cr.openjdk.java.net/~anthony/7u6-4-fxHang-7159266.0/ With this fix we avoid setting an application delegate when AWT is started in the headless mode. This prevents a hang when another GUI toolkit (e.g. JavaFX) is already running in the same Java process. This would logically mean that you won't get eAWT events (file open, quit, etc) while started in this mode. Does this impact SWT as well? In the headless mode an application doesn't have any UI, and as such there's no way to generate e.g. a Quit action. Hence the application delegate isn't necessary in this mode. SWT uses a special SWT mode (== -XstartOnFirstThread) which is different from the headless mode. In the SWT mode the delegate will still be installed. I think this may not work in case of running an SWT application together with the AWT in headless mode. However, I can't imagine who might want to run SWT/AWT in such configuration because the headless mode is supposed to be primarily used in server environments where a display is physically unavailable, in which case SWT wouldn't be able to run there either. -- best regards, Anthony
Re: AWT Dev [8] Review request for 7148275: [macosx] setIconImages() not working correctly (distorted icon when minimized)
This seems like a reasonable approach, though setting window icons is generally discouraged on OS X. Regards, Mike Swingler Apple Inc. On Apr 2, 2012, at 7:16 AM, Anthony Petrov wrote: Hi Mike, Have you had a chance to take a look at the issue? -- best regards, Anthony On 03/27/12 20:49, Anthony Petrov wrote: On 3/27/2012 8:44 PM, Anthony Petrov wrote: Artem: this is a good idea, thanks. Mike: I'm trying to do something like this: http://cr.openjdk.java.net/~anthony/8-15-lowResIcon-7148275.1/ i.e. I'm feeding an NSImage with images of all available sizes. A sample test provides a list of icons 16x16, 32x32, 48x48, and 64x64. I've verified that they all get added into the representations array. However, even if I resize the dock to be very very tiny, it still chooses the 64x64 icon to represent a minimized window. This is actually wrong since the 16x16 icon would look better in this case than a resized 64x64 icon. Any idea how this can be fixed? Another solution would be to take an approach similar to what we use on MS Windows: we query the system icon size, and then choose the best image (see SunToolkit.getScaledIconData()). But I can't find API that Rather WWindowPeer.updateIconImages() which calls the SunToolkit method. -- best regards, Anthony would allow me to determine the current dock icon size on OS X. Is there any? -- best regards, Anthony On 3/26/2012 5:19 PM, Artem Ananiev wrote: It was fine for 7uX, but can we do anything better for JDK8? Is the largest icon always the best? I remember on Windows we use another approach to find what exactly icon from the list to apply. Thanks, Artem On 3/23/2012 8:18 PM, Anthony Petrov wrote: Hello, Please review a fix for http://bugs.sun.com/view_bug.do?bug_id=7148275 at: http://cr.openjdk.java.net/~anthony/8-15-lowResIcon-7148275.0/ This is a direct forward-port of the same fix from 7u4. More details: http://mail.openjdk.java.net/pipermail/macosx-port-dev/2012-March/003531.html -- best regards, Anthony
Re: AWT Dev [7u4] Review request for 7124428: [macosx] Frame.setExtendedState() doesn't work for undecorated windows
On Mar 16, 2012, at 10:18 AM, Anthony Petrov wrote: Hello, Please review a fix for http://bugs.sun.com/view_bug.do?bug_id=7124428 at: http://cr.openjdk.java.net/~anthony/7u4-7-setExtendedStateUndecorated-7124428.0/ It looks like OS X handles the -zoom request incorrectly for undecorated windows. Therefore we have to emulate it in our code. I'd suggest pulling the logic for choosing undecorated into the constructor, making the private boolean undecorated final, and then just relying on the value inside of getInitialStyleBits(). Making the undecorated boolean final serves as a warning to others in the future. Otherwise, this looks great. Cheers, Mike Swingler Apple Inc.
Re: AWT Dev [7u4] Review request for 7148275: [macosx] setIconImages() not working correctly (distorted icon when minimized)
On Mar 8, 2012, at 8:17 AM, Anthony Petrov wrote: Hello, Please review a fix for http://bugs.sun.com/view_bug.do?bug_id=7148275 at: http://cr.openjdk.java.net/~anthony/x-23-lowResIcon.0/ Looks good to me. Regards, Mike Swingler Apple Inc.
Re: AWT Dev [7u4] Review request for 7145818: [macosx] dialogs not showing when JFrame is in full screen mode
There are a few points here:
* If the user marks the window as fullscreenable using the eAWT API, that
puts a widget in the upper right corner of the window which allows the user to
toggle it into full screen themselves.
* When in full screen (using AWT or eAWT API), the user should be able to click
the blue exit fullscreen button in the menu bar at any time (if they entered
into full screen themselves)
* Generally, it is undesirable for the user to be stuck in a state where they
cannot return to the desktop.
With the current diff, the isFullScreenMode boolean in Java will definitely be
out of sync if the user initiates either of these actions.
Instead of trying to keep the knowledge of the full screen state in Java behind
a lock, I think you probably need query native to see if the window is in the
fullscreen state. I've used the following testcase to test the existing eAWT
fullscreen API, and I think you'll find it's easy to get into a state where the
user is stuck in windowed mode without a menu bar, and that sometimes the user
is locked out from returning to windowed mode when they clicked on the window
widget.
After trying out your diff, I actually found it quite frustrating that the
menubar was suppressed and I *had* to use the four-finger swipe gesture to get
back to my desktop. How would you feel about just dropping the whole menubar
hiding stuff? Since the menu bar is auto-hidden by default, users don't get to
it unless they push up to the top of the screen anyway.
Try out this test case, and be sure to use the window widget, as well as the
button that programmatically fires the eAWT API.
import java.awt.*;
import java.awt.event.ActionEvent;
import javax.swing.*;
import com.apple.eawt.AppEvent.FullScreenEvent;
import com.apple.eawt.*;
public class FullScreenTest {
public static void main(String args[]) {
SwingUtilities.invokeLater(new Runnable() {
public void run() { createFrame(); }
});
}
static void createFrame() {
JFrame frame = new JFrame();
frame.setDefaultCloseOperation(JFrame.EXIT_ON_CLOSE);
frame.setTitle(System.getProperty(java.version));
Container contentPane = frame.getContentPane();
contentPane.setLayout(new BorderLayout());
contentPane.add(createPanel(), BorderLayout.CENTER);
// turns on the fullscreen window titlebar widget in the upper
right corner
FullScreenUtilities.setWindowCanFullScreen(frame, true);
// useful for re-adjusting content or hiding/showing palette
windows
FullScreenUtilities.addFullScreenListenerTo(frame, new
FullScreenAdapter() {
public void windowExitingFullScreen(FullScreenEvent e)
{
System.out.println(exiting);
}
public void windowExitedFullScreen(FullScreenEvent e) {
System.out.println(exited);
}
public void windowEnteringFullScreen(FullScreenEvent e)
{
System.out.println(entering);
}
public void windowEnteredFullScreen(FullScreenEvent e)
{
System.out.println(entered);
}
});
frame.pack();
frame.setVisible(true);
}
static Component createPanel() {
final JPanel panel = new JPanel(new FlowLayout());
// toggle FullScreen from a toolbar button
panel.add(new JButton(new AbstractAction(Full Screen Me!) {
public void actionPerformed(ActionEvent e) {
Application.getApplication().requestToggleFullScreen(
(Window)panel.getTopLevelAncestor());
}
}));
return panel;
}
}
Regards,
Mike Swingler
Apple Inc.
On Mar 2, 2012, at 6:42 AM, Anthony Petrov wrote:
A tiny typo has been fixed, a new webrev is at:
http://cr.openjdk.java.net/~anthony/x-21-popupInFullscreen-7145818.2/
--
best regards,
Anthony
On 3/2/2012 6:20 PM, Anthony Petrov wrote:
Thanks for your suggestions Mike. Here's the latest version of the fix:
http://cr.openjdk.java.net/~anthony/x-21-popupInFullscreen-7145818.1/
--
best regards,
Anthony
On 3/2/2012 3:14 AM, Mike Swingler wrote:
On Mar 1, 2012, at 1:10 PM, Anthony Petrov wrote:
Hi Mike,
Thanks for the review! Please see my comments inline.
On 3/1/2012 9:31 PM, Mike Swingler wrote:
On Feb 29, 2012, at 6:58 AM, Anthony Petrov wrote:
http://cr.openjdk.java.net
Re: AWT Dev [7u4] Review request for 7145818: [macosx] dialogs not showing when JFrame is in full screen mode
On Feb 29, 2012, at 6:58 AM, Anthony Petrov wrote: Hello, Please review a fix for http://bugs.sun.com/view_bug.do?bug_id=7145818 at: http://cr.openjdk.java.net/~anthony/x-21-popupInFullscreen-7145818.0/ Thanks Mike for the suggestion to use the [NSWindow toggleFullScreen] API. I've tested the fix on both 10.7 and 10.6.8, and it works consistently on both systems. Although the new API is claimed to be supported starting with 10.7 only, it works fine on my 10.6.8 box as well (but prints out a warning about sending an unrecognized selector to an AWTWindow instance.) I've also verified that the native resize events contain correct window size, so I removed the machinery that sent synthetic events in the full screen mode. A few points to consider: * To protect against the unrecognized selector problem, you should test if the AWTWindow object -respondsToSelector:@selector(toggleFullScreen) before just calling it. * Also, there is already API that calls -toggleFullScreen in the eAWT classes that you might not be aware of. You should probably test for interactions with that, since apps can opt their window into having a full screen widget icon and independently toggle fullscreen. * In some cases, seeing the menubar is actually desirable, where as in the exclusive mode, it's probably not. Perhaps you could consult a client property on the window to determine if the menu bar should be hidden? I like this overall solution, because it uses the native platform concept of full screen which doesn't trap the user from switching spaces like the Java SE 6 implementation did. Regards, Mike Swingler Apple Inc.
Re: AWT Dev [7u4] Review request for 7145818: [macosx] dialogs not showing when JFrame is in full screen mode
On Mar 1, 2012, at 1:10 PM, Anthony Petrov wrote: Hi Mike, Thanks for the review! Please see my comments inline. On 3/1/2012 9:31 PM, Mike Swingler wrote: On Feb 29, 2012, at 6:58 AM, Anthony Petrov wrote: http://cr.openjdk.java.net/~anthony/x-21-popupInFullscreen-7145818.0/ A few points to consider: * To protect against the unrecognized selector problem, you should test if the AWTWindow object -respondsToSelector:@selector(toggleFullScreen) before just calling it. I'm aware of -respondsToSelector. But I suppose that in that case this simply won't work on 10.6.8 at all. Since a) presently it does work on 10.6.8 for reasons unknown, and If OpenJDK is built on Snow Leopard, it works fine. I believe the problem is the X11/FreeType versions in Lion are newer, and DYLD won't load libraries linked against older versions. But that is going to start me on my rant about how OpenJDK should bundle it's own FreeType... b) we officially support 10.7+ only, hence the check makes little sense in theory, and Please think of OpenJDK, not just Oracle's proprietary binaries. There are other users who currently compile on Snow Leopard and this is not an inconvenience, since 10.7-only API is very rare in the JDK. c) from ObjC perspective sending an unknown selector isn't an error, but just a warning, It is extremely poor form. The -respondsToSelector: check is very cheap, and is very obvious what it is guarding against. it seems to me that having this warning printed out to the console (which isn't seen by 99% of users anyway) is OK when running on 10.6.8. Plus we get the full screen working there. Isn't it awesome? We know there are developers and users who will be running OpenJDK on Mac OS X 10.6.8, so it is perfectly reasonable to add this as an OS guard. We should not actively damage our ability to run on 10.6 if it's trivially avoidable. * Also, there is already API that calls -toggleFullScreen in the eAWT classes that you might not be aware of. You should probably test for interactions with that, since apps can opt their window into having a full screen widget icon and independently toggle fullscreen. Thanks for pointing this out. I'll rework this code to make sure calls from EAWT update the boolean flag. Great. * In some cases, seeing the menubar is actually desirable, where as in the exclusive mode, it's probably not. Perhaps you could consult a client property on the window to determine if the menu bar should be hidden? Excellent idea! I think that by default the menu should be hidden (for Java spec's sake). But if a client property is set, then the menu would be visible. Cool. There are several client property readers already on the root AWT window that should be easily extendable. I like this overall solution, because it uses the native platform concept of full screen which doesn't trap the user from switching spaces like the Java SE 6 implementation did. We've noticed an interesting detail with -toggleFullScreen when it's used in a multi-screen environment. In that case the window will go full screen on the biggest monitor (actually we have a MacBook with an external monitor connected.) The OS seems to ignore the screen where the window were before entering the FS mode (the main notebook display). Is this OK? Can we force it to use the same screen where the window is originally located for the FS mode? It's actually the monitor with the menu bar (the primary, as designated in the Monitor's preference pane). This is an issue with the OS, and should be filed at http://bugreporter.apple.com (it's known, but if you have a specific API suggestion to target a screen, or some sort of automatic behavior in mind, it would be good to provide specific suggestions in the bug). Thanks, Mike Swingler Apple Inc.
Re: AWT Dev Review request for 7142120: [macosx] Some JCK tests for SplashScreen fail on Mac OS X due to incorrect positioning of the splash
On Feb 3, 2012, at 5:22 AM, 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. All the failing tests now pass well with this fix applied. Also [NSScreen mainScreen] gives you the screen that the main (aka active) window is on. You really should use the 0'th screen to get the primary screen with the menu bar and the Dock. Regards, Mike Swingler Apple Inc.
