Re: [platform-swt-dev] Mac OS X Port

["Steve Northover/OTT/OTI" <Steve_Northover@xxxxxxx>]

Hello Chris,

Your observations about SWT are bang on.  I've got a question for you.
When a new feature is added to the operating system, how is the API
exposed?  For example, do you get .h or .cpp (or .class :-P).  The reason
I'm asking is that whatever mechanism Apple uses to expose their API
is probably the mechanism that SWT need to use to call that API.

Another question:  What language is used to implement new graphics
and window system features on the Mac?  I realize that this doesn't matter
but I'd like to increase my knowledge of the platform.  For example, in the
old, old days, it was Pascal.

Steve

Chris Thomas <kenshin@xxxxxxxxx> Sent by: platform-swt-dev-admin@xxxxxxxxxxx 11/14/01 05:33 PM Please respond to platform-swt-dev

To:        platform-swt-dev@xxxxxxxxxxx         cc:                 Subject:        [platform-swt-dev] Mac OS X Port

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