[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [platform-swt-dev] Mac OS X Port
|
Hi
I have done a feature scrape from "Learning Carbon" and "Learning Cocoa"
Most of the things necessary to get SWT to run under Cocoa are found in
the AppKit. You have the following:
UI Objects (windows, views, panels .. )
Services (dnd, pasteboard, localization, printing etc)
I love my X because (color, sound, video, images and all the other
goodies)
Carbon is made up of a lot of managers
UI objects (appearance, control, dialog, menu and window mangers)
Services (scrap, drag, font, icon, folder, alias and scripting managers)
and I love my X because goodies ....
I think features pretty much track one for one with respect to the
requirements for SWT. Carbon events are callback based while Cocoa
events are delegation based. I think the best insight you had was the
fact that you identified the fact that JCocoa is a peer to SWT, in that
they are semantically equal. I think that pretty much rules out JCocoa
unless OTI would allow the designers to violate the key design patterns
with respects to the porting layer (making eclipse widgets subtypes or
wrappers of NSObjects). As I wrote earlier, I don't think the aqua port
should fork the design.
The key distinction between Cocoa and Carbon is the former is object
oriented while the latter isn't. Cocoa is objective-C which is a
superset of C so one of the initial strategies I followed when I first
got Eclipse (pre open source) was to try and figure our if the JNI layer
could invoke Objective-C Cocoa API. I know that Objective-C methods can
invoke C functions and i vaguely remember that the reverse works as
well. I wrote to a couple of news groups but I got no response.
Nevertheless, such an approach is potentially doable, we then get
java-->c-->objectivec-->c-->java. If it is done, then SWT effectively
becomes equivalent to JCocoa. The fact that Apple already did this means
that such an approach should work. In this scenario, the drivers of the
port would be ex-nexties and objective-c gurus.
For Carbon, I must say porting would be relatively transparent as the
port would maintain the unity of the original OTI implementation and
design. The essential design patters and implementation patterns would
be the same and OTI would be most comfortable with the end result as I
would not be "that" different from the other platforms. In this
scenario, the drivers of the port would be carbonites and OTI.
<-- begin my two eurocents-->
From an emotional perspective I am most enthusiastic about Carbon mainly
because I know my C and JNI. But there is that curious george bit in me
who wants to know X for what it really is, NeXTSTEP. Then there is the
philosophical issues, I love objects, and even though objectivec seem
weird at first sight (my sincere apologies to smalltalkers), there is
something pleasing about objects all the way through.
<--end my two eurocents-->
In the end it need not matter that much (who know, with enough people,
we could do a CarbonSWT and a CocoaSWT). I just hope that we get a port
done before summer next month. And then I shall try and convince IBM to
release Websphere workbenches on X and then I can finally and completely
leave my Windows behind me.
Some practical matters, what build environment are we going to use?
ProjectBuilder, GNUMake?
Cheers
On Wednesday, November 14, 2001, at 06:33 PM, Carolyn MacLeod/OTT/OTI
wrote:
Eclipse wouldn't run on older Macs because it uses Java 2 and Apple
has no plans to have Java 2 on a MacOS < 10.
SWT does not need Java2 - we are pretty careful about stuff like that.
If any Java2 code has crept in, I am sure it is minimal and isolated,
and
can be rewritten quickly if required.
Too bad Eclipse needs Java2. Rats. :(
No, you get Aqua with Carbon on MacOS X, but you loose some of the
niceties of Cocoa (like really nice looking antialiased text).
I had read that you don't get it all, but I wasn't sure what you lost.
Thanks for clarifying that you get most of it.
What else are you giving up if you use Carbon-Aqua instead of Cocoa?
Anything important?
Microsoft and many other companies are porting their apps to Carbon
only, not to Cocoa!
And its not easy to spot the difference to Carbon apps!
Good news - makes sense to me.
Carolyn
Andre Weinand <weinand@xxxxxxx>
Sent by: platform-swt-dev-admin@xxxxxxxxxxx
11/14/2001 04:33 AM
Please respond to platform-swt-dev
To: platform-swt-dev@xxxxxxxxxxx
cc:
Subject: Re: [platform-swt-dev] Mac OS X Port
Carolyn wrote:
I think you need to be absolutely certain that you don't care about
all the older Macs out there,
because Cocoa won't work with older versions of the Mac OS.
Eclipse wouldn't run on older Macs because it uses Java 2 and Apple
has no plans to have Java 2 on a MacOS < 10.
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.
I found exactly these kinds of problems and gave up with Cocoa.
(It would sure be more natural to port SWT to Carbon...
Yes, the Carbon event model is a good fit to SWT because its similar
to the Windows API.
but then, of course, you don't get Aqua...)
No, you get Aqua with Carbon on MacOS X, but you loose some of the
niceties of Cocoa (like really nice looking antialiased text).
Microsoft and many other companies are porting their apps to Carbon
only, not to Cocoa!
And its not easy to spot the difference to Carbon apps!
--andre
_______________________________________________
platform-swt-dev mailing list
platform-swt-dev@xxxxxxxxxxx
http://dev.eclipse.org/mailman/listinfo/platform-swt-dev
_______________________________________________
platform-swt-dev mailing list
platform-swt-dev@xxxxxxxxxxx
http://dev.eclipse.org/mailman/listinfo/platform-swt-dev
