Am Freitag, 18. Januar 2013 um 04:26 schrieb Carl Marcum: > On 01/17/2013 05:19 PM, Rob Weir wrote: > > On Thu, Jan 17, 2013 at 10:02 AM, Jürgen Schmidt <jogischm...@gmail.com> > > wrote: > > > 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. > > > > > > > > > So speaking of communications... What's the plan? > > > > If we're really going to make incompatible changes, we should probably > > do more than put it in release notes or Bugzilla. It should probably > > go into a blog post, with advance notice and a link to technical > > details. > > > > How many month's notice would be enough? Can some update before a new > > release? Or would we need to provide a "beta" SDK? > > > > -Rob > > > > > > > Juergen > > Will this effect tools like the Netbeans plugin that would need updated > or modified to create a new extension compatible with 4.0? > >
yes the generated Addon.xcu has to be adapted. > > If so where could I find the information needed? see the issue above or take a look in the examples. It's no big thing Juergen > > Thanks, > Carl > >
