What Still Needs to be Done to Complete the Mac OS X 10.0.x Port?

As of the OO638C release tag, only the modules in the Abstraction and Infrastructure Layers of OpenOffice.org have been ported. Accordingly, a full build of OpenOffice.org is not possible at this time. The purpose of this document is to provide a list of all of the known tasks that need to be done to create an installable and runnable version of OpenOffice.org for Mac OS X 10.0.x.

For all items in the list, it is assumed that the developer has been able to build all of the modules in the Abstraction and Infrastructure Layers of OpenOffice.org and can successfully run their test programs. For instructions on how to build the Abstraction and Infrastructure Layers of OpenOffice.org on Mac OS X 10.0.x, see the build instructions.

Warning: This list is only applicable to the OO638C release tag and Mac OS X 10.0.x. Due to the continuing enhancement in functionality of OpenOffice.org, developers may find tasks that need to be done that are not on this list.

Task	Description
List of Remaining Mac OS X 10.0.x Porting Tasks
Get remaining modules to compile	As of the OO638C release tag, about half of the modules are able to be compiled on Mac OS X 10.0.x. Hence, the remaining modules need to be made to compile before the installation program and OpenOffice.org itself can be run. Although nearly all of the code in the remaining modules is platform independent, developers will find many instances where the code will not compile without some changes. Most of the required changes will fall into one or more of the following categories: Mac OS X 10.0.x compiler and other technical issues - For an extensive list of such issues, see the issues page. Missing native code - By default, if there is native windowing code, the build will try to build the X11-based windowing code. In such cases, you will need to create a new platform-dependent directory and create the necessary C++ class implementations and C functions to support Mac OS X's windowing APIs. For an example of how to create a new platform-dependent directory, take a look at the dtrans/source/aqua and the dtrans/source/X11 directories in the source code.
Unicode font support	The current code only supports printing of ASCII characters and only supports printing using the default system font. In order to support the Western European languages that OpenOffice.org supports on other platforms, printing of Unicode characters needs to be implemented. Also, in order for OpenOffice.org to have a smooth appearance, support for multiple fonts and font sizes needs to be implemented. The current font support for Mac OS X 10.0.x is implemented in the vcl/aqua/source/gdi source directory.
Java 1.2 JNI support	The Java 1.1 JNI APIs do not work correctly in Mac OS X 10.0.x's native Java Runtime Environment (JRE). So, the current Java support for Mac OS X 10.0.x uses Java 1.2 JNI APIs. This implementation, however, is very minimal, in that the only configuration that has been implemented is setting of the JRE's CLASSPATH. In order for OpenOffice.org to properly interact with the Java 1.2 JNI APIs, the implementation needs to be expanded to include setting of the following items: JRE command line options (e.g. stack size, debug port, etc.) System properties The current JNI API support for Mac OS X 10.0.x is implemented in the stoc/source/javavm source directory.
Dialog modality	OpenOffice.org's vcl module does not rely on native code to implement modal windows. Instead, the platform-independent code uses emulated modality by controlling the stacking order of modeless windows. In the current implementation, the code controlling the stacking order is not connected to the Mac OS X 10.0.x native windows. The current Mac OS X native event handling support is implemented in the vcl/aqua/source/app source directory and the platform-independent event processing is in the vcl/source/window source directory.
Setup program native code	The setup program uses some native event handling code to control the installation process. This native code has been implemented. However, it has not been tested. Hence, some debugging should be expected. The current native event handling code for the setup program is in the setup2/aqua/source/loader source directory.
Printer support	No printing support has been implemented. In the OO638C release tag, all of the printing related C++ methods contain empty implementations. Hence, these empty methods need to be implemented to enable the following OpenOffice.org functionality: Printer identification and selection Rendering to the selected printer The empty C++ methods for printer support are in the vcl/aqua/source/gdi source directory.
Full screen graphics support	No full screen graphics support has been implemented. In the OO638C release tag, all of C++ methods that route text and graphics rendering to the desktop contain empty implementations. Hence, these empty methods need to be implemented to enable OpenOffice.org's full screen functionality used within OpenOffice.org's presentation code. The empty C++ methods for full screen graphics support are in the vcl/aqua/source/window source directory.
Sound support	No sound support has been implemented. In the OO638C release tag, all of C++ methods that enable loading and playing of sound files contain empty implementations. The empty C++ methods for sound support are in the vcl/aqua/source/gdi source directory.
Copy and paste support	No copy and paste support has been implemented. In the OO638C release tag, all of UNO C++ methods that enable copying and pasting of multiple content types contain empty implementations. The empty C++ methods for copy and paste support are in the dtrans/source/aqua source directory.
Drag and drop support	No drag and drop support has been implemented. In the OO638C release tag, all of UNO C++ methods that enable dragging and dropping of multiple content types contain empty implementations. The empty C++ methods for drag and drop support are in the dtrans/source/aqua source directory.
Database support	OpenOffice.org requires the Berkeley DB database to support its internal database functionality on Linux. Hence, this piece of open-source software might be required on Mac OS X 10.0.x as well. If this software is required, it will need to be ported to Mac OS X 10.0.x. Links to the Berkeley DB source code can be found at www.sleepycat.com.
OpenGL graphics support	OpenOffice.org uses the OpenGL APIs to render 3D graphics. In the OO638C release tag, all of C++ methods that connect the platform-independent code in the vcl module to the native OpenGL functions contain empty implementations. The empty C++ methods for OpenGL support are in the vcl/aqua/source/gdi source directory.
Encapsulated PostScript (EPS) graphics support	OpenOffice.org supports rendering of EPS to windows and printers. In the OO638C release tag, all of C++ methods that support rendering of EPS contain empty implementations. The empty C++ methods for rendering EPS are in the vcl/aqua/source/gdi source directory.
3rd party plugin support	OpenOffice.org makes use of third party libraries to perform some functionality on other platforms. These libraries, like Netscape or Internet Explorer plugins, can render graphics within a clip region of an OpenOffice.org window. No third party plugins are known to be required for OpenOffice.org to run on Mac OS X 10.0.x. However, if a third party plugin is needed or desired, the SalObject C++ class will need to be implemented for Mac OS X 10.0.x. In the OO638C release tag, all of SalObject C++ methods contain empty implementations. The empty SalObject C++ methods are in the vcl/aqua/source/window source directory.