On 1/17/13 12:24 PM, Bernard Marcelly wrote: > Hello, > > I read report 121577 and did not notice the problem. > <https://issues.apache.org/ooo/show_bug.cgi?id=121577> > > Then I found this in the dev mailing list : > <http://www.mail-archive.com/dev@openoffice.apache.org/msg02906.html> > "I noticed that add-on extensions with toolbars have a problem on trunk. > The ext can be installed but the toolbar is not visible and also not in > the View -> Toolbars menu. Top-level menus coming with the same ext are > visible. I am currently don't know if it is related to the bigger > changes with the name or something else in the context of add-on, means > the framework part." > > As you can read in answers to this thread, it means that the next > version of Apache OpenOffice will be _incompatible_ with _all_ > extensions created before. > > Such a case should only happen for a compelling reason. > I think this is not the case. Bug 121577 is introduced only for a futile > purpose: > "the extension developer has to create a configuration file > <Module>WindowState.xcu for every office module where the toolbar is to > be displayed, even if the toolbar name will be exactly the same in every > module." >
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. > This is futile because it is not a big simplification of the creation of > the various xml files of an extension. In fact the only "human" way of > creating the numerous files of an extension is to use a tool. Then the > invoked complexity or tediousness (almost) disappears. See : > <http://wiki.openoffice.org/wiki/Extensions_Packager> > > Of course an extension packager can be modified to the new addon syntax. > The problem is not here, it is that all existing extensions will not > work as designed unless they are each modified. And modified extensions > will not be compatible with previous versions or with LibreOffice. as far as I know is LibreOffice changing a lot of API's as well and do a lot of cleanup, remove deprecated etc. It is probably a good idea to test extensions against both in the future. The differences will probably become bigger if we won't find a way to work together. Juergen
