Mac OS X Porting - contributions from NeoOffice
Contents
Introduction
Collaboration between OpenOffice.org and the NeoOffice -project has an ugly history. It is one of those things that one finds hard to be neutral about. You either hate NeoOffice, or love their work.
Despite this, there has been smaller and bigger contributions coming from NeoOffice to OpenOffice.org, every once in a while. It's very far from perfect, but it's something.
We at OpenOffice.org must stop hating others and spreading bad words. Our attitude must be honorable, no matter what others do.
The purpose of this page is to record all the contributions NeoOffice has done to OpenOffice.org. Maybe this makes one appreciate the history more.
The philosophical differences
OpenOffice.org for Mac OS X porting efforts were started by the original Mac OS X porting team: Patrick Luby, Ed Peterlin, Dan Williams, et. al. There was a falling out of sorts between the OpenOffice.org community and Sun Microsystems, who was Patrick's employer at the time. (Details are not available as to what happened and why.) This resulted in the original group leaving the OpenOffice.org community and founding a project of their own: NeoOffice.
The NeoOffice project has lead to a native Mac -looking derivative of OpenOffice.org. What this project basically did, was to use Carbon/Java to create a GUI wrapper around the basic OpenOffice.org application code.
The parts of code that are only in NeoOffice, are under GPL licence (e.g. the GUI wrapper). Since OpenOffice.org only accepts LGPL licenced code, it is not possible to directly include NeoOffice code in OpenOffice.org. For this reason NeoOffice project is not supported by OpenOffice.org.
Since around 2004 or 2005, there has been a new Mac OS X porting team in OpenOffice.org, lead by Eric Bachard. The OpenOffice.org's native Mac OS X porting effort is called Aqua. This effort is using different approach than NeoOffice - The team uses Carbon/Cocoa for the GUI wrapper.
In 2006, there was a decision by the OpenOffice.org organization to move all information about NeoOffice.org to the derivatives page, as NeoOffice.org is and will continue to be a derivative.
It should be noted that several individuals in NeoOffice and OpenOffice.org -projects continue efforts to "mend the bridge" between these two projects. Although it is very unlikely that things will get better any time soon.
Any one of these actions would significantly help the situation:
- friendly behaviour towards the "other" project, no matter what opinions the others have
- NeoOffice contributing to OpenOffice.org small or bigger fixes that they have fixed in NeoOffice, but are not in OpenOffice.org. (see the patch bomb below)
- joint collaboration on design and feature specification/priorisation, or with new APIs (e.g. related to Apple HIG), or just lots of beer
- general feedback from one project to the other
Important facts
OpenOffice.org is a trademark. NeoOffice is a trademark. These trademarks have to be respected.
While respecting the above rights, it is completely LEGAL and correct to say:
- NeoOffice is a derivative of OpenOffice.org (about 95% of code in NeoOffice comes from OpenOffice.org CVS)
- NeoOffice is based on OpenOffice.org (The GPL license in NeoOffice permits including LGPL licensed OpenOffice.org code)
- NeoOffice is similar to OpenOffice.org (NeoOffice has same menus, (at least) same functionality and almost the same look as OpenOffice.org)
There is a difference in speech between coders and users:
- Coders look at NeoOffice and say that it is very different from OpenOffice.org
- Users look at NeoOffice and say that it is very similar to OpenOffice.org
We do not want to confuse or anger the users. When talking to users, we must agree with them that the two applications are similar.
Contributions in the OpenOffice.org 1.x timeframe (years 2000-2003)
The Mac OS X porting team in OpenOffice.org at that time consisted from three (3) core developers:
- Dan Williams (fa@openoffice.org) - After OOo 1.1 left completely the OpenOffice.org scene
- Ed Peterlin (openstep@openoffice.org) - After OOo 1.1 went to co-found the NeoOffice project
- Patrick Luby (pluby@openoffice.org) - After OOo 1.1 went to co-found the NeoOffice project
with some other contributors infrequent contributors such as:
- Terry Teague - maintainer of Start OpenOffice.org -script, which was needed for OOo 1.1 (Terry Teague died suddenly and was a great contributor to both projects)
The three core developers worked on Mac OS X for X Windows (X11) port, starting completely from scratch. The linux/unix X11 port of OpenOffice.org of course existed already, but because of openoffice.org code base, the porting to Mac OS X was still a herculean task. Not the least because of the bridges -module, which requires platform specific assembler language(!) -coding.
The current (2006) OpenOffice 2.x X11 port for Mac OS X continues to benefit from this pioneer work.
Summary of major contributions:
- A fully functional OpenOffice.org X11 port for Mac OS X, written from scratch
- Very polished (although X11) version of OpenOffice.org to Mac OS X (e.g. support for different printing implementations on Mac OS X 10.0 - 10.3, OpenOffice.org starter app, installable .pkg in a disk image)
- Very active and effective bug fixing on Mac OS X
After OpenOffice.org 1.1, the OpenOffice.org X11 port for Mac OS X was revitalized by the current OpenOffice.org team. Porting from 1.1 to 2.0 turned out to be very big task and also the huge effort to support for Apple's Macs with Intel processors resulted in yet another new bridge -module completely written from scratch (again).
Contributions during OpenOffice.org transition from 1.x to 2.x (years 2003-2005)
Around the time OpenOffice.org 1.1 was released Patrick and Ed founded the NeoOffice, project. No longer employed by Sun, nor in any other relationship with them, they wanted to explore the Mac OS X native port in full focus.
As a result, an effort was created, to make OpenOffice.org GUI more easier to port to different platforms (instead of using the same OpenOffice.org's own GUI in every platform). This resulted in the VCL plugins API.
As part of this VCL API work, actually some preliminary structure and some pieces of early implementations for native Mac OS X were committed to openoffice.org CVS and issuezilla.
Parallel to this, highly experimental OpenOffice with Cocoa (the NeoOffice/C -project) porting feasibility study was conducted in the years 2002-2004 by NeoOffice people. It never finished due to the recognition of challenges too hard to solve, between the OpenOffice.org (1.x) and Cocoa (as it was in 2003).
NeoOffice people re-started the NeoOffice project, this time using Java as the GUI glue. This was deemed as the fastest way to get the native port ready. Eventually this work resulted in a one-time contribution to OpenOffice.org, the "patch bomb" (PB) of fixes to OpenOffice.org 1.x from Patrick Luby, in summer 2005. It contained small, but important fixes. This code was also reworked in cws_macjoin1153 for OpenOffice.org 1.x.
Around the same time the current OpenOffice.org Mac OS X porting team began their own native porting effort (the Aqua), starting from the preliminary pieces that were in the OpenOffice.org CVS. Unfortunately it turned out that most of the actual implementation was badly outdated and needed to be written again.
The integration of PB for X11 was very slow due to OpenOffice.org people's lack of interest in outdated (1.x) code and the need to port it to 2.x. Also OpenOffice.org developers were very careful in evaluating whether the code was:
- still relevant
- the optimal/correct fix
- proper/suitable for the new 2.x codebase
Summary of main contributions:
- major participation to the design and definition the VCL plugins API (the API for platform specific "GUI widgets" currently in use since OpenOffice.org 2.0)
- contributions in OpenOffice.org CVS for a native Mac OS X port using VCL plugins. Unfortunately the implementations turned out to be mostly outdated and needed rewriting the code.
- The feasibility study of OpenOffice.org porting to Cocoa, leading to profound understanding of the difficulties and possibilities of using Cocoa in OpenOffice.org
- A "patch bomb" of fixes to OpenOffice.org 1.x from Patrick Luby, sent to the (then current) developers of OpenOffice.org 2.x for Mac OS X developers (in summer 2005).
Detailed list of fixes resulting from the "patch bomb" (PB):
- (in OOo 2.1+) The PB pointed to issues with locking and network drives. It is a very complex problem. The openOffice.org developers have created their own fixes for these issues: AFP (Apple Filesharing) Issue 62229, NFS (Network File Storage) problems Issue 61865, locking problems Issue 61865, Issue 62521
- (in OOo 2.0.4+) The PB pointed to problems in printing and resulted in a big cleanup and fixing of cups (cws macosxcups). The actual new code was not derived from the PB.
- (in OOo 2.0.4+) Temporary filename fixes. Not used, but resulted in a important cleanup of temporary file code. issue 64399, 64421 and 64420 and cws pj54 & vcl59.
- (in OOo 2.0.3+) The Mac aliases were not working (at all). The code from PB was used to fix it Issue 61959
- (in OOo 2.0.3+) The PB identified problems with using and displaying non-ascii characters (UTF8). The PB code was not directly used, but a better solution was created Issue 61958 (cws pj51)
- (in OOo 2.0.2+) Dynamic library (dl / dl-compat) issues, which were outdated, but lead to good cleanup of the code.
(this list is not complete yet)
Latest contributions
Summary of contributions:
- The PB still contains e.g. the native locale support code for: sal/systools/macxp_extras/x11osx/osxlocale.c - This has not been integrated and continues to be potentially important for native port.
- presentation at the OOoCon 2006, presenting the challenges of porting OpenOffice.org. The insights.
- At OOoCon 2006, pointers to future development in NeoOffice, enabling also OpenOffice.org developers to be proactive, instead of reactive to features important to the users
- NeoOffice represents the baseline in user-friendliness and features that also OpenOffice.org for Mac OS X should (at the least) reach for.
