And so it begins :)

[Rob Ross]

Woo hoo. Happy to see this day finally arrive.

So, first, a question: What is "TOT", as in "Needs refresh from Apple TOT"?

http://wikis.sun.com/display/OpenJDK/Mac+OS+X+Port+Project+Status





Next, on the Aqua LaF, I'd like to suggest that it behave like any "regular" Swing LaF, where drawing is done via Java2D APIs, and not calling back into the native environment to use heavyweight peers for drawing and event handling. Sure, it's more work in the short term, but I think it has many advantages.

First, it avoids calling native methods via JNI (at the low level it's all JNI), which makes rendering faster. Aqua is a pretty LaF for Java, but it's also the slowest rendering LaF in popular use. ( I've heard this from the Swing & Java2D team at the last 3 JavaOne conferences, so if anyone wants to start a flame fest on this point, please email them.)

Second, it allows for customization in drawing that works for every other LaF except Aqua or SWT. Things you can do in Metal/Ocean/Windows LaFs and others sometimes just don't work in Aqua. For example, I have many printing issues when trying to use customized drawing, where printing works fine on other platforms but not on Aqua.

Third, having all the drawing code rendered on the Java side means it's easier to tweak that code to have a high fidelity with the native Cocoa look & feel. This may sound counter-intutive at first, but if this weren't the case there would be no need of frameworks like Quaqua or  MacWidgets which exist to "fix" problems in the "native" Aqua implementation, so the Java UI more closely resembles the native Cocoa UI.

Fourth, having all the UI code on the Java side makes it easer to enhance, change, and add new UI features to the LaF and doesn't require writing JNI code to access that new functionality on the native Cocoa side. A UI delegate implementation in pure Java also doesn't have to worry about the particular version of Mac OS X; so if new FooUI is introduced into Swing, we don't have to rely on native platform details to render it, we just draw and manage events on the Java side. This works better for portability as well.

There are probably other good reasons as well, e.g. "All the other LaFs do it this way", although that in itself is not the best reason. But consistency is a worthy goal.

Thoughts?


Rob