Hi Gerhard,
see my comments inline ...
Gerhard Schuster wrote:
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.
mmm, a useless statement with out any concrete examples, isn't it
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.
i would agree but i would also say that too many different solutions
don't really help users to find their way.
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.
not necessarily if the prio would be set correct
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.
well you are right, we would get a lot of examples
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.
sure otherwise it wouldn't work anyway
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.
sorry but that is completely nonsense, we simply focus on NetBeans
because it is a Sun open source project. And i think that is 100% ok. We
can't do anything. Ask Cedric who has mentored him during the Google
Summer of Code project. At this time we started two projects one for
Eclipse and one for NetBeans.
And of course we explicitly designed the uno-skeletonmaker as a command
line tool that it can be used in other IDE's as well. I work often close
together with Cedric and give him support where necessary.
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.
we never prevent that we simply make it a little bit easier for
NetBeans. We support anybody who want to do something similar for other
IDE's.
Sometimes i have the feeling that it is regardless what Sun is doing
somebody will always complain about it. If we do more for NetBeans than
Eclispe than it is wrong if we prefer Java more than Python it is wrong.
If Sun sponsor Sun open source projects with a lot of money it is wrong
and Sun is bad ... I don't understand it.
The OpenOffice API is complicated. All code examples in the
DevelopersGuide are from the core team and all of them are out dated.
sorry but that is again nonsense. Of course there are API's where we
have better API's today but they are not out dated. I am sure that all
of them work.
Why not open up and provide a place where to publish code?
because it needs somebody who do it and it costs money.
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 100% agree, i always say that examples and good documentation are the
key points to attract new developers.
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.
i think that is not true if people really want help and if they are
really interested to help in the existing projects then they will get
all the necessary support.
I agree that we can improve a lot here and we are working on it.
Anyway I will think about a place where we can host this kind of helper
libraries. I can't promise anything but can at least offer to host it in
the API project where you would have cvs access and can create your own
web page under the umbrella of the API project that would be of course
a good place for it. By the way the Eclispe plugin source code is hosted
there as well ;-)
Juergen
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
