Difference between revisions of "Mac OS X Porting - contributions from NeoOffice"

From Apache OpenOffice Wiki
Jump to: navigation, search
(The philosophical differences)
 
(24 intermediate revisions by 3 users not shown)
Line 12: Line 12:
 
==The philosophical differences==
 
==The philosophical differences==
 
    
 
    
NeoOffice.org was begun out of the original Mac OS X porting team, Patrick Luby, Ed Pertilin, 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.)  The lead to the original group leaving the OpenOffice.org community support team and founding a project of their own, NeoOffice.orgThis project has lead to a Mac GUI style version oSeconf OpenOffice.org.  What this project basically did is use Carbon/Java to create a wrapper around the basic OpenOffice.org application code that creates the sensation that one is using a Mac Native program with all of the appropriate menus and displays.  However, this code is on top of the original OpenOffice.org code and this project is not supported by OpenOffice.org.
+
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.   
  
There is another effort, lead by the current Mac OS X porting team, called AquaThis team is growing and changing but the original lead in this effort is Eric Bachard.  This project has made great progress in using Carbon/ObjC (the C programming language for the Mac).
+
The NeoOffice project has lead to a native Mac -looking '''derivative''' of OpenOffice.orgWhat this project basically did, was to use Carbon/Java to create a GUI wrapper around the basic OpenOffice.org application code.  
  
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.
+
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.'''
  
It should be noted that several members of the NeoOffice.org support team continue efforts to "mend the fences" with the OpenOffice.org team.
 
The first of these should be 'bring backs' of code that fixes problems in the current version of OpenOffice.org that would help both projects become easier to use.
 
  
Second, the path to mend the fences would be for the NeoOffice.org team to join the OpenOffice.org team to finish the work on the Apple HIG version being constructed and completed by the OpenOffice.org team.
+
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 [http://trinity.neooffice.org/modules.php?name=News&file=article&sid=120 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)==
 
==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:
 
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  
 
* '''Dan Williams''' (fa@openoffice.org) - After OOo 1.1 left completely the OpenOffice.org scene  
* '''Ed Peterlin''' (?@oo.org) - After OOo 1.1 went to co-found the NeoOffice project
+
* '''Ed Peterlin''' (openstep@openoffice.org) - After OOo 1.1 went to co-found the NeoOffice project
* '''Patrick Luby''' (?@oo.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:
 
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''' - 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 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.
Line 40: Line 63:
 
* 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 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
 
* 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)==
 
==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.
+
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 [http://gsl.openoffice.org/vcl/plugins/ VCL plugins] API.
 
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 [http://gsl.openoffice.org/vcl/plugins/ VCL plugins] API.
  
Parallel to this, highly experimental OpenOffice with Cocoa (the [http://neowiki.sixthcrusade.com/index.php/History_of_NeoOffice_and_OpenOffice.org:_NeoOffice/C 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).
+
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.
  
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.
+
Parallel to this, highly experimental OpenOffice with Cocoa (the [http://neowiki.sixthcrusade.com/index.php/History_of_NeoOffice_and_OpenOffice.org:_NeoOffice/C 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).  
  
The integration of PB 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:  
+
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 "[http://porting.openoffice.org/servlets/ReadMsg?list=dev&msgNo=15387 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
 
#  still relevant
 
#  the optimal/correct fix
 
#  the optimal/correct fix
Line 59: Line 89:
 
'''Summary of main contributions:'''
 
'''Summary of main contributions:'''
 
* major participation to the design and definition the [http://gsl.openoffice.org/vcl/plugins/ VCL plugins] API (the API for platform specific "GUI widgets" currently in use since OpenOffice.org 2.0)
 
* major participation to the design and definition the [http://gsl.openoffice.org/vcl/plugins/ 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
 
* 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).
+
* A "[http://porting.openoffice.org/servlets/ReadMsg?list=dev&msgNo=15387 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):'''
+
'''Detailed list of fixes resulting from the "[http://porting.openoffice.org/servlets/ReadMsg?list=dev&msgNo=15387 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) [http://www.openoffice.org/issues/show_bug.cgi?id=62229 Issue 62229], NFS (Network File Storage) problems [http://qa.openoffice.org/issues/show_bug.cgi?id=61865 Issue 61865], locking problems [http://qa.openoffice.org/issues/show_bug.cgi?id=61865 Issue 61865], [http://qa.openoffice.org/issues/show_bug.cgi?id=62521 Issue 62521]
 
* (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) [http://www.openoffice.org/issues/show_bug.cgi?id=62229 Issue 62229], NFS (Network File Storage) problems [http://qa.openoffice.org/issues/show_bug.cgi?id=61865 Issue 61865], locking problems [http://qa.openoffice.org/issues/show_bug.cgi?id=61865 Issue 61865], [http://qa.openoffice.org/issues/show_bug.cgi?id=62521 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+) 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. [http://www.openoffice.org/issues/show_bug.cgi?id=64399 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  [http://qa.openoffice.org/issues/show_bug.cgi?id=61959 Issue 61959]
 
* (in OOo 2.0.3+) The Mac aliases were not working (at all). The code from PB was used to fix it  [http://qa.openoffice.org/issues/show_bug.cgi?id=61959 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 [http://qa.openoffice.org/issues/show_bug.cgi?id=61958 Issue 61958] (cws pj51)
 
* (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 [http://qa.openoffice.org/issues/show_bug.cgi?id=61958 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)
 
(this list is not complete yet)
Line 75: Line 107:
  
 
'''Summary of 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.  
 
* presentation at the OOoCon 2006, presenting the challenges of porting OpenOffice.org. The insights.  
* pointers to future development in NeoOffice, enabling also OpenOffice.org developers to be proactive, instead of reactive to features important to the users
+
* 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.
 
* NeoOffice represents the baseline in user-friendliness and features that also OpenOffice.org for Mac OS X should (at the least) reach for.
  
Line 83: Line 116:
 
* [http://neowiki.sixthcrusade.com/index.php/History_of_NeoOffice_and_OpenOffice.org:_Introduction Brief history, from NeoOffice perspective]
 
* [http://neowiki.sixthcrusade.com/index.php/History_of_NeoOffice_and_OpenOffice.org:_Introduction Brief history, from NeoOffice perspective]
 
* [http://neowiki.sixthcrusade.com/index.php/NeoOffice_and_Aqua NeoOffice and Aqua]
 
* [http://neowiki.sixthcrusade.com/index.php/NeoOffice_and_Aqua NeoOffice and Aqua]
 
+
* [http://www.openoffice.org/editorial/edp_and_danw.html Interview from 2002: Ed Peterlin and Dan Williams on building OpenOffice.org for Mac OS X]
 
+
[[Category:Porting]]
+
 
[[Category:MacOSX]]
 
[[Category:MacOSX]]
[[Category:Aqua]]
 

Latest revision as of 11:01, 16 December 2009

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:

  1. still relevant
  2. the optimal/correct fix
  3. 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.

Related links

Personal tools