Hey,
I'm another Java developer that was shocked that OS X wasn't on the
roadmap
for upcoming SWT ports. Many thanks to OTI & IBM for opening the
source so
that we can fix that!
On 11/12/01 10:33 AM, "Suhail Ahmed" <ilyanov@xxxxxxx> wrote:
My mistake. Allow me to call it JCocoa if you will. I agree with you
about bypassing the JNI layer. Given that the question decomposes to
where to encapsulate JCocoa calls. Should we do it in the widgets
packages or in the internal packages by creating an aqua package.
I don't think that a org.eclipse.swt.internal package at all. Apple has
done all that for us in com.apple.cocoa.application &
com.apple.cocoa.foundation. Since all of Cocoa is available to us as
Java
classes, no native code needs to be written.
At a glance it looks like most if not all of SWT can be mapped
directly to
Cocoa by writing Adapters (wrappers). For example
org.eclipse.swt.graphics.Color would map to
com.apple.cocoa.application.NSColor and org.eclipse.swt.widgets.Button
would
map to com.apple.cocoa.application.NSButton. Not all of them are so
obvious, but I think you get the picture.
The biggest thing that I am struggling with so far is what actually is
the
SWT API? I was expecting a set of interfaces with separate
implementations
for each platform, but I'm not finding it. Can someone with SWT
knowledge
help out here?
Another big problem I'm having getting started with this thing is CVS
and
the build environment. It looks like you need to be using Eclipse to
manage
the large project/sub-projects layout and handle the multiple identical
class definitions. Is it normal when beginning a port to a new
platform to
cross compile until Eclipse is up and running on the new platform?
-Maurice