Re: Incompatible change for extensions
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 ModuleWindowState.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
Re: Incompatible change for extensions
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. Regards Bernard
Re: Incompatible change for extensions
On 1/17/13 3:00 PM, Bernard Marcelly wrote: 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. exactly and that is the reason why I would today add a max version dependency always. I know 4.0 will be next, I would change the max version dependency to 4.0 after testing that everything works and would do a micro release if I change nothing else. 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. This would be a situation that is always bad. If you use unmaintained code you can run always in such trouble. In this specific case the oxt can be changed easily and the Addon.xcu can be adapted, repackage the oxt and that's it. No real code changes and you don't have to remove any XXXWindowState.xcu if you have one. I would love to have much more time to fix API design bugs or change some bad API's to make the life for developers easier in the future. I was a big fan of compatible API's but learned over time that good API's have to evolve over time. We didn't do that and the API is often not easy to use and to understand in many areas. We can improve a lot here but probably not compatible. I have a mixed feeling about it but believe that it will help us to make the product better over time. This is an easy change, other API changes that require real code changes will be more difficult to communicate. As long as we communicate and document these kind of changes and provide migration paths we are on a good way I think. We have to look forward. Juergen
