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

[Suhail Ahmed <ilyanov@xxxxxxx>]

Hi again

I hear you. But consider accessing the com.apple.cocoa.* via the porting 
layer provided in the internal packages. It would allow the aqua port of 
SWT true to the original eclipse design pattern for porting. Instead of 
having native method signatures in the OS class we could declare them as 
being "pure" java methods and then delegate the calls via OS interface 
to com.apple.cocoa.* classes. By using JCocoa we will be forking 
significantly from the eclipse implementation patterns, if you look at 
the OS class, that is actually encouraged but IMHO we should not fork 
the overall design pattern as well. Within the design, the widgets  
packages depends on the internal packages and the internal packages 
depend on native JNI library. We could lose the JNI library and have the 
internal packages instead depend on Cocoa.

I have the same problem with the SWT API. I found this article 
http://www.eclipsecorner.org/articles/Article-SWT-Design-1/SWT-
Design-1.html quite useful in understanding stuff. Over the next couple 
of day, I am going to reverse engineer the UML model from the source and 
find things out. I will put the results up on a webpage and let you all 
know.

Cheers

> 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