Future direction brainstorming...

[OPENSTEP]

Oh frig. Yup, with Cocoa all the Yields need to be in the main thread. If you poke inside of the Aqua vcl_HandleEvent() function inside of Neo (I think that's the right one), you'll see all kinds of convoluted mutex guards and communication to try and dispatch yields to the main thread to fetch the event, pass the event back to the yielding thread, then continue on in the thread. Watch out doing this, however, as some AppKit calls also need to be called from the main thread, so continuing to handle the event off of the main thread can lead to further thread safety issues. Unfortunately, Apple hasn't documented what parts of AppKit are thread safe and which are absolutely required to be invoked on the main thread...it's all kind of trial and error. But definitely things that are poking around with the event queues need to be on the main thread from my experience.

The good news for 1.0.3 over 638C is that most, but not all, of the SalApp::Yields tend to be on the same thread, so if you can find a way to finesse the event handling onto the main thread then you may be golden.

There was an easy way to schedule calls to execute on the main thread synchronously in Carbon with the MPRemoteCall() function (that is a link). I'm not sure if it could be helpful for you.

This is another reason why, for really nitty gritty work, I've still received some "off-hook" advice that it's somewhat easier to stick with carbon

ed

[pluby]

Ed,

Well I finally figured out how to get Java 1.4.1 to work within NeoJ (and OOo). Unfortunately, it really messes up OOo. As you probably know, OOo tends to have an expectation of which thread follows which thread. As a result, the OOo threads have a tendency to yield only to each other and, as result, the Java event dispatching thread never runs or runs too infrequently.

Also, I found that most of the problems with Java 1.4.1 were due to incompatibilities arising from loading the JavaVM framework in a library loaded via UNO. I finally figured out that this loading of the JVM in UNO causes the Cocoa code within the JVM to not be able to find the functions that are registered for the java.awt.* native methods.

Not suprisingly, if you make an executable that is linked to both the Cocoa and the JavaVM frameworks, you can use the Java Invocation API to create a JVM and you can draw simulatenously in multiple pthreads. Of course, I still need to start the Cocoa run loop first, but it never crashes.

Lastly, I found that even if I hack up NeoJ to load Java without going through UNO, it works but the Font.layoutGlyphVector() method does not do any ligature or style replacement. Of course, if you do this in test program that I mentioned above, liguture and style replacement work perfectly. I suspect that this is due to lazy binding of Cocoa since in OOo main() is in a shared library.

So what does all of this mean? Well, it basically means that Java 1.4.1 is no longer the easy way to enable ligature and style replacement in text drawing. In fact, I have found that Mac OS X's Java 1.4.1 implementation is so fussy when run via Java Invocation API, that I am abondoning work on it and redirecting my time to something more useful: printing.

The good news is that just because we cannot use Java 1.4.1 on Mac OS X does not mean we can't support ligature and style replacement. When we upgrade to the OOo 1.1 code, we can use ICU's text layout engine. ICU is a required component in OOo 1.1 and so their layout engine comes at a very minimal cost and is platform independent. The only downside is that ICU will probably not handle the style replacement for fonts like Apple Chancery but ICU should be able to handle language dependent ligature and style replacement (i.e. Arabic).

I did leave the stoc and vcl code in the neojava cvs module for those that are interested in Java 1.4.1 on Mac OS X. However, since stoc modifications are not part of the build, NeoJ will still load Java 1.3.1.

Patrick