Saturday, September 13, 2008

Continuing with Cocoa SWT

I had some problems building the JNI code for Cocoa SWT on my MBP.  First, I didn't want to get sidetracked by building a specific XulRunner SDK, so I just downloaded the 1.9.0.1 binary available from mozilla.org.  Next, I had to make a couple minor modifications to org.eclipse.swt/Eclipse SWT PI/cocoa/library/make_macosx.mak.  After specifying the proper location for XULRUNNER_SDK, I still ran into the following problem in the build:

[exec] /Library/Frameworks/XUL.framework/Versions/1.9.0.1-sdk/sdk/include/nsStringAPI.h:1053: error: size of array 'arg' is negative
That line contains:

  PR_STATIC_ASSERT(sizeof(wchar_t) == 2);
A quick C program proved that wchar_t was actually 4 bytes on my machine.  After commenting out  the HAVE_CPP_2BYTE_WCHAR_T define in mozilla-config.h within my xulrunner install, I reran the build from Eclipse, and everything compiled.  Now on to the actual work of adding NSFormatter and NSNumberFormatter to the JNI code.

Wednesday, September 3, 2008

First steps into SWT/Cocoa

As I recently picked up a MacBook for myself, I've decided to put some effort in to contributing to the SWT/Cocoa port. First step, is choosing a bug. I'm relatively new to both Cocoa and SWT development, so I decided to start with something that should be relatively easy. I chose bug 222791. First step was to write a simple Cocoa app with a a spinner type control written natively. Turns out that an SWT Spinner is simply an NSTextField and an NSStepper which are linked together. The way Cocoa validates text entered into an NSTextField is through a formatter associated with that field, and specifically by sending the following message:
- (BOOL) isPartialStringValid: (NSString  *)partialString
         newEditingString: (NSString **)newEditingString
         errorDescription: (NSString **)errorDescription
This is where things get a little trickier. This method is called from Cocoa, not from our Java application, but the SWT mindset is that the OS wrapper should be as thin as possible. I shouldn't just write up an NSFormatter in native code and reference it from Java. Rather, I need to find a way to trampoline this Cocoa callback into our Java code. Naturally, there are plenty of examples of this, especially in the Display class for the Cocoa port, but OS.java (when I started) did not contain the above selector. My easy bug has quickly morphed in to something requiring me to regen the JNI layer for SWT... Time for a bit more research before I can really dig my teeth in.