[platform-swt-dev] Mac OS X Port

[Chris Thomas <kenshin@xxxxxxxxx>]

Hi. I've been lurking for a few days and wanted to clarify a few things. Apologies in advance for the length.

- Cocoa is not going away. It is the primary object-oriented language API for programming Mac OS X applications.
- Carbon is not going away. It is the primary C language API for programming Mac OS X applications.

I think there's some confusion about what exactly the SWT approach is, and exactly what the Cocoa Java bridge is. If experienced SWT folks could correct any mistakes in the following logic, I'd appreciate it.

If I understand what I've read, the core SWT architecture for platform-independence can be expressed in two points:

(1) The "native" GUI toolkit for a platform is exposed through Java (in the OS class) in as direct a manner as possible, preserving all behaviors, including features and bugs, of the native toolkit APIs.

(2) All custom logic that is part of the SWT framework (including workarounds for native toolkit bugs), is encapsulated in Java code (in the widget classes specific to the platform).

What Apple provides as an Objective-C <-> Cocoa bridge is not just a (more or less) one-to-one mapping of Cocoa to Java: it is a fully-supported native API for accessing the Mac OS X GUI. Much effort has been expended by Apple to debug and optimize this bridge. There's no reason to duplicate this work, and it would be very difficult to do so effectively.

That is to say, Apple has already provided the fully-functional equivalent of the OS class, (1).

I personally think the only reasonable options for porting SWT to Mac OS X are

- JNI to Carbon APIs
- using the Java bindings for Cocoa

It seems to me that the latter is far less work for an initial prototype port, but Carbon may ultimately allow more flexibility.

Doing anything else unnecessarily duplicates work that's already been done.

Carolyn MacLeod/OTT/OTI <Carolyn_MacLeod@xxxxxxx> said:
> The more I read about Cocoa (not just Java-Cocoa, any Cocoa), the more it looks like an SWT peer to me (where peer == "same level", not "AWT peer").
> As such, it is probably going to be difficult to port SWT to, because of event loop issues and other random problems that come up when you try to port on top of something that is really at the same level as you, and has already solved all of the same problems that you solved, possibly in different ways.
> (It would sure be more natural to port SWT to Carbon... but then, of course, you don't get Aqua...)
> Cocoa is also beginning to smell a lot like Swing, if you don't mind me saying, because it's got that model-view-controller thing going on...

If you want to look at it that way, both Cocoa and Carbon are peers of SWT, at least in their current incarnations. Cocoa/Objective-C and Cocoa/Java are fully supported native interfaces to the same implementation of Aqua, Carbon is a different native implementation of Aqua.

I think it makes more sense to think of Cocoa (Objective-C and Java) and Carbon as native implementations of the platform user interface: both are appropriate candidates for the native layer. Either Cocoa or Carbon should be flexible enough to handle SWT's needs; if they aren't, appropriate bugs should be filed at http://bugreporter.apple.com/.

It's also important to realize that (for the purposes of SWT) both Carbon and Cocoa are actually event-loop based. Most applications never need to directly interact with the event loop, so it isn't the first thing that you learn when you read about Cocoa or Carbon, but it is there, and you can wrest control and dispatch events yourself. I don't see a fundamental reason offhand why one couldn't derive an SWT port from either. You don't lose much with Carbon (drawers, nice text); you do gain some flexibility. Cocoa's view and graphics models are much nicer than Carbon's equivalent functionality, however.

Suhail Ahmed <ilyanov@xxxxxxx> said:
> Carbon events are callback based while Cocoa events are delegation based

Sort of. Both Carbon and Cocoa applications pull events from an event queue. Carbon dispatches events through event handler callbacks which an application can override. Cocoa dispatches events by calling Objective-C methods. You handle hardware events (mouseDown) in Cocoa by overriding methods in subclasses; delegation is often used for higher-level operations (populating a table, resizing a window).

I'm not currently on any of the Carbon, Cocoa, or Java teams, so do take all of the above with an appropriately-sized grain of kosher salt.  :)

Chris