Preliminary review for MACOSX_PORT-176: AWT Splashscreen support

[Mike Swingler]

On Dec 7, 2011, at 7:52 AM, Anthony Petrov wrote:

> Hi Mike and team,
> 
> Here's what I've coded up so far:
> 
> http://cr.openjdk.java.net/~anthony/x-3-splashAndOSXGUILib.0/
> 
> Note that instead of moving the NSApplicationAWT code to the libosxui, I instead introduced a new libosxapp. This is because osxui has too many dependencies on the AWT while we start the splashscreen even before calling user's main() method. Perhaps we could move some code from osxui to osxapp eventually, but not at this time.
> 
> So, in a nutshell, the libosxapp is now responsible for creating and setting up an NSApplicationAWT instance. Note that since the splash screen takes off too early, user's code (e.g. SWT) won't be able to initialize their own application yet, and as such our application instance will be installed. Which means that our splash screen implementation is incompatible with SWT-based apps. By this reason I also didn't move the start up code from awt.m to the new libosxapp - it's simply isn't needed in case the osxapp is used from the splash screen code. Is this OK with everyone? Or are there suggestions on how to improve this part?
> 
> In NSApplicationAWT.m there is an outstanding TODO item: we need to be able to install a "caching app delegate" so that we could catch all the openFile and other start-up notification, and then call the necessary methods manually once a proper application delegate is installed from the awt.m code. Note that we need this caching only when the splash screen is used. If an app doesn't use the splash screen, then the correct delegate is installed right from the start.
> 
> Please take a brief look at the fix. Does it look good overall?
> 
> I could push it now actually, and continue to work on the mentioned above issues separately, or I could complete them first, and then push my fix. Note that I'm not sure if the SWT-related issue has any reasonable solution at all, but the delegate callbacks caching mechanism needs to be implemented sooner or later anyway.
> 
> What would be the best to do now?

A few notes:

* I think it makes sense to move the PropertiesUtilities class into libosx, where the rest of the non-UI stuff lives right now, and just link libosxapp against that (since it's useful from libosx, libosxui, and libosxapp). It probably makes sense to move the ThreadUtilities class to libosx too, for the same reasons.

* You can remove the "AppKitThreadHelper" class. It is redundant with +[JNFRunLoop performOnMainThreadWaiting:withBlock:] or simply doing a -performSelectorOnMainThread: using the NSObject class itself as the target.

* Is the expectation that libosxapp be a common substrate that JavaFX or SWT can launch itself with AppKit directly without the AWT being involved? If so, a design question you may want to ask is, should the com.apple.eawt.* event handling be available from these other frameworks? I know SWT has had an interest in using the eAWT, and would jump at the opportunity to have have to load the AWT to do so.

* I find it more than a little amusing that my last re-write of the eAWT event handling explicitly created queues for incoming events (prior to client code registering their handlers), but I put the queues on the Java side, and now you need them on the native side. I think the easiest way to handle this will to simply wrap the work of the event handlers in a block, dump those blocks into an NSArray (since blocks are objects), and then pump them onto the main queue once the eAWT handlers have been registered. This may also allow you to delete some of the queueing/locking code up in the Java side of the eAWT implementation.

Regards,
Mike Swingler
Apple Inc.