Hallo Juergen,
I would have given up on OpenOffice if not Oliver Brinzing had provided an example Eclipse project with a build.xml file and some java examples. Oliver also mentioned that no one can use the OpenOffrice API without writing his own helper classes. I found out that he is absolutely right. When I was working as in software testing, another department had developed a general to use test API. It turned out that it was not usable without helper classes. The other department never managed to include our helper classes because they did collide with their internal dessign. I think that this is due to a conflict in targets. The API developer first of all wants to keep his API nice and neat. The end user first of all wants to solve his problems. JS> Please give us the necessary feedback that we can focus on the most JS> often used and most important API's with our improvements. I only use a tiny fracture of the capabilities of OpenOffice. I can not claim to know the most important API's. I think the best way to learn about the most important future improvements would be to encourage the users to publish their helper classes. The publishing process has to be easy to use. I think that publishing through a revision controll system would be the easiest way. If there would be a statistic that tells how many people contributed to and uses a special helper class, you would know which OpenOffice API's to improve. JS> But i would prefer to think about a language JS> independent approach. In my opinion that is the second step. A solution like this sounds like years away (OpenOffice 4.0 or later) whereas helper classes are arround already. Having redundant helper classes for different languages is no drawback in my opionion. You could see which language is the most popular. Also it would mean that there would be much more public code examples arround in diferent languages. Any way, the comunity had to be in charge of the repository. The author and the users of a helper class had to provide testing, documentation and make shure the helper classes would work with a given OpenOffice version. I think many people would contribute code in their favourite language, who would never work on the OpenOffice core. A repository would also be the place for out of the box example projects for the most popular IDE's and languages. There is no support for Eclipse beside Cedric's plugin. Sun does not like Eclipse. Ok, but I think it is more important to encourage developers to write code for OpenOffice, using any kind of IDE they like, then to promote NetBeans (which is by far not the most popular IDE) via the retour over OpenOffice. The OpenOffice API is complicated. All code examples in the DevelopersGuide are from the core team and all of them are out dated. Why not open up and provide a place where to publish code? The more helpers and example projects there are arround, the more people would consider to code with OpenOffice, the more code would be arround, the more people would code for OpenOffice, ... I have the feeling that the OpenOffice developers are disapopinted about the lack of public contribution but on the other hand, they don't want to give things out of their own hands. This is a vicious circle. -- Best regards, Gerhard mailto:[EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
