[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
Re: [platform-swt-dev] Re: Mac OS X Port by Carolyn MacLeod
|
Hi,
I suggest that we all post our resume, so that we can just all see who
has the most Mac development experience. It probably won't me... :)
Me neither :-(
If we use the Java Cocoa binding for the OS X port, we have a three
level binding:
SWT widget -> Java Cocoa widget -> native Cocoa widget. From the SWT
philosophy, this is one level to much.
As I see it, the SWT philosophy has three layers too.
1. A public SWT API every plugin developer can use (SWT widgets)
2. A wrapping layer for native calls
3. A platform specific UI API
The difference with Cocoa is that
1. Cocoa is an OO widget framework, in contrast to all those procedural
frameworks.
2. Java Cocoa is a wrapping layer supplied by the UI API supplier. The
source is not open, so you can´t be sure what exactly happens and most
importantly you can´t fix bugs or increase performance easily. Still we
have to condier it a choice, since its usage should decrease development
time.
SWT to native Cocoa,
Java-Cocoa to native Cocoa
both are thin layers. If you use the three level approach, you make it
a fatter binding.
You don´t loose much by calling Java Cocoa from SWT. You _just_ don´t
control the code of the native mapping anymore.
I see the problem with that, but I´d give it a try. Later on you still
can change to JNI if the approach proves buggy/slow/too complex to
handle/...
What we formally can measure is the memory usage difference. I think
that the preference of going JNI/JDirect or JCocoa is a matter of
personal preference. To comply to the SWT idea, I prefer the JNI or
JDirect approach, also for similarity between the various ports.
I don´t think using Java Cocoa contradicts the SWT idea. In contrast
adapting an OO framework like JCocoa to SWT would show the flexibility
of the SWT concept.
I agree with you, that a JNI/JDirect approach ensures similarity between
various ports - but that can only be one of many more important reasons
to use JNI/JDirect.
Think different. *g* (applies to my own position as well)
martin