Message de Jürgen Schmidt  date 2013-01-17 13:19 :

I disagree, the old mechanism is a design bug and should be resolved. It
was always planned to fix this a major release. Now with 4.0 we can make
such changes and we had long discussions about incompatible changes for
major releases. Extensions can be easy updated and by the way it is
always a good idea to add a max version dependency and release a new
version of your extension if you have ensured that it works with the
newest office version. How many unpublished API's are used in extensions
that can change at any time?

We probably don't have enough time to fix many more design bugs in the
API for 4.0 but this one is definitely worth the change. We will
document it and the fix is easy. But for all new extensions the usage is
much more intuitive and less error prone.

The current mechanism is not a design bug (because it works), rather a clumsy design.

To create a toolbar with the same name in Calc, Draw, Impress, you have to:
- create one WindowState xcu file
- make 2 copies of this file
- modify one line in each copy
- add entries for these files in the manifest.xml
Is this really complex, error prone ? I don't think so, compared to all other features of an extension.

About max version dependency : application developers don't see the future. It's not possible to know in advance when (and why) an extension will become incompatible.

In the context of a company that has created a specific extension, happily used for years, Apache OpenOffice 4.0 will be a bad surprise. Releasing a new version will be difficult: the original developer may have gone, or have forgotten the building details of an extension; a new developer has to learn the syntax of an oxt file, and find out what has to be changed to make it work again. Costs, delays. Benefits ? None.


Reply via email to