openoffice-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From zhangjf <>
Subject Re: Next steps for Symphony and AOO
Date Tue, 12 Jun 2012 03:28:02 GMT
On Tue, Jun 12, 2012 at 10:10 AM, Pedro Giffuni <> wrote:
> On 06/11/12 20:08, Rob Weir wrote:
>> As we wait [0] for the Symphony [1] code to be loaded into Subversion
>> I think it would be good to start a discussion on "next steps" of how
>> we can make best use of this contribution.
>> Hopefully you've had time to review the list of features on the wiki
>> [2], install one of the binaries [3] , or maybe even download the
>> source [4] and try to build it [5].
>> As will see by your examination, the Symphony code base has co-evolved
>> with for several years now, and continued to co-evolve
>> with Apache OpenOffice even recently.  Symphony has many features and
>> bug fixes that AOO lacks.  And there are areas where Symphony is
>> missing enhancements or bug fixes that are in OpenOffice.
>> Our challenge is to find the best way to bring these two code bases
>> together, to make the best product.
>> I think there are two main approaches to this problem:
>> I.  Merge code, from Symphony, feature by feature, into AOO, in a
>> prioritized order.  This is the "slow" approach, since it would take
>> (by the estimates I've seen) a couple of years to bring all of the
>> Symphony enhancements and bug fixes over to AOO.
>> II.  Use Symphony as the the new base, and merge (over time) AOO (and
>> OOo) enhancements and bug fixes into the new trunk.  This approach
>> quickly gives a new UI, something we could fairly call Apache
>> OpenOffice 4.0.  But this approach would also give us some short-term
>> pain.   For example, those involved in porting AOO 3.4 would need to
>> merge their patches into the new trunk.   We'd need to update license
>> headers again.  Help files and translation are done differently in
>> Symphony, and so on.
>> Looked at another way, option I is a slow, but easy path.  Option II
>> is a leap forward, but will be initially more work and disruption.
>> Evolution versus Revolution.
>> So let's discuss.  Please ask questions about the pro's and con's of
>> each approach.  The code and binaries are all posted, and my IBM
>> colleagues in Beijing are happy to answer your questions.
> Wow ...
> First of all let me ask one question:
> Can we really not have the java components from Symphony?
> We do have Java stuff already and even if it may not seem so,
> Eclipse is not really a problem since we can ship Category B
> binaries.

The Java components in Symphony are implemented on Lotus
Expeditor(XPD) libraries and running on it's workbenches. Such as the
multi-tabbed documents, toolbar, status bar... XPD has a more modern
UI comparing to OpenOffice's own one. Technically they should also
work if they are migrated to Eclipse RCP. But it also has it's own
shortage. There is big impact on performance and need great effort on
UX integration, and it is hard to maintain the communication and
integration between the two processes. Personally I don't think AOO
will make such big changes in a short period.

While some pieces of Java code which doesn't heavily depends on XPD
libraries can be migrated to OOo AWT controls with small effort, Or
even we can keep using the RCP libraries for more fancy UI, such as
the mail merge.


> Concerning the dilemma:
> - Option (I) can basically only be done well by the Symphony
> guys because they know the changes well enough and only
> they have access to the history. It will likely take them a lot
> of time and we may lose some features in the process and
> we will never know.
> -On option (II) we can all help as we all have access to the
> Hg repositories and we can use svn merge for the changes
> AOO has done. There is the unfortunate risk that we might
> have issues merging some of the pre-Apache changes.
> This may also lead to inconsistencies between 3.4 and 4.0.
> For me option II is more mechanical and although it may
> seem more work (redo the BSD port!) it is less effort and
> more predictable. I would go with that one: merging AOO
> into Symphony.
> Pedro.

View raw message