From: Braden M. <br...@en...> - 2007-06-21 22:44:14
|
I have access to a machine running Mac OS X (10.4), and I'm beginning to put some effort into making OpenVRML behave better on this platform. This initial effort is going into making things work with the MacPorts toolchain. As of this writing the trunk builds with the MacPorts tools, sans openvrml-xembed, openvrml-player, and the Mozilla plug-in. I have added a configure option --with-libjs that facilitates linking against the libjs binary that is typical of the stand-alone SpiderMonkey distribution (rather than libmozjs that is included with Mozilla/Firefox). This will likely come in handy in other build scenarios as well. Since I don't anticipate much interest in an openvrml-player that requires X11 on Mac OS X, I doubt I'll be spending any energy on making that work. But if someone happens to be interested in this, it shouldn't be that hard. Instead, I would like to get openvrml-player and the Mozilla plug-in working with Carbon and/or Cocoa. I'd like that, but unfortunately I don't think it's going to be easy. My investigation thus far indicates that the Mac GUI frameworks have no support for out-of-process GUI components. That means that the pattern by which openvrml-player and the Mozilla plug-in share the same back-end (openvrml-xembed) simply won't work on the Mac. So as things currently stand, a port will not be as simple as mapping functionality from one API to another. I don't yet know enough about Carbon/Cocoa to know what the right way to resolve this is. One possibility is that functionality in openvrml-xembed and openvrml-player might be factored out into libraries that can be used by different processes on X11 platforms and different threads on Mac OS X. Braden |