This support is great, but we need to do something about segregating it from the core until the _NSLockError stuff is resolved. I've already had to help a couple people resolve the issue on the Mac. By including it by default in the core library and having it break on one of the main three platforms is going to create problems. And, unfortunately, not everyone has seen the original post that discusses it.
We need to find a clean way to move it to an optional separate area for download.
Suggestions?
Perhaps we could get a build from the ongoing SWT-cocoa port project, even if it was only stable enough to shut up compile errors.
That would be fine as well. Just need to get it to compile.
Understood. I'll see what I can do to get a cocoa jar in place this weekend.
Well, after much trying I was able to build the cocoa swt build, but oddly enough putting it in my classpath still gave me the issue. I'm really not sure why since I can run the eclipse tests now, but ah well.
So, instead I've made empty versions of all the classes, interfaces and methods that we currently touch in swt and jarred that up into a swt_fake.jar file you can now find in /lib/swt/macosx-cocoa. The old carbon swt is now in macosx-carbon for those on older macs. Let me know if there are any further issues. Sorry for the trouble.
I'll cross-post this to the external thread and my blog.