[EMAIL PROTECTED] wrote:
Hi Pierre-Andre,

Selon Pierre-André <[EMAIL PROTECTED]>:


First of all, I would like to apologize for the delay in my answer. Holydays
with no internet connection are very good for resting but not so good for
developping ;-)


Hollidays aren't normally given to developp ;-) However I did it...


Quoting Pierre-André <[EMAIL PROTECTED]>:

First of all, I would like to thank-you for taking the time to do this
integration with Eclipse ! It will help developpers to gain precious time
!

I thank you for your effort to get time to improve my work :-) Eclipse
people have tested a bit the plugin to help me correcting some bugs.

For now, I was not able to find the time to test your plug-in, but will try
to
manage it as soon as possible ( I hope before the end of the week) !


Philippe Ombredanne wrote a small article on my work and OpenOffice.org
development. You can find it here :
http://eclipse.techforge.com/index.php/article/171. He asked me to write
something more precise when I would get more time, if you already have
ideas we could write a common article to promote OpenOffice.org development
:-)

I would be glad to do so ! You can contact me directly if you want some help.

To give some feedbacks (even if I have still not tested your plug... I hope
not to tell to many non-sense) here are some ideas. A feature which could be
nice would be to select different types of projects. When working with
OpenOffice.org, I noticed, that different "types" of projects can be coded :

- a component (with IDLC...).
- a new menu (linkied with code).
- linking it with external libraries or external code (QT...). This could
allow an application to communicate with OOo easily.
- Import / Export filters (C++, Java or XSL)
- ...

The initial idea of the google summer of code projects (eclipse and netbeans integration) was to provide several project types. 1. IDL wizard (which can be part of the other wizards if necessary, e.g. component implmenting new interfaces))
1. general UNO component wizard
2. add-on component wizard
3. calc add-in component wizard

Where the latter both are more or less specialized versions of the first one. The integration should also provide basic tasks for developing UNO, configuration of SDK environemnt, code completion (most often IDE feature), UNO package creation (all component project types), deployment of UNO packages, compiling IDL files (compile IDL files, create project specific type library, generate Java class files). In C++ the last step would produce the necessary header files. There is a lot of work and Cedric and Fintan have done the first steps in the right direction. I am currently working on a code skeleton generator which should be used later from this integrations to produce some code. The advantage of this approach is that we generate always the same code (independent of the used IDE), it is easier to change if we need changes because of internal changes, improvements or maybe better helper classes and that we can use it for C++ as well. The IDE integrations would collect the necessary info, run the code generator and configure the projects that a component after finishing the wiazrd would be buidable and deployable out of the box. In a second step the developer would exchange the default method bodies with useful implementations.

In the future we can think about more specialized wizards and of course this can include filter wizards.


Giving the choice to select which type of project each one wants to develop
could help and create more specific code.


For the moment I have developped a new wizard to create generic OOo projects.
There is an editor for idl files and all the compiler chain for Java. The next
release adds a new service wizard: this helps a idl writer to create a new
service (as specified in the OOo2.0 grammar). This will lead to more specified
wizards for Calc and Chart add-ins, Add-ons and remote OOo clients.

We should limit the service wizard to new style services only because we want to push the creation of this services and multiple inheritance interfaces instead of old style services. Or better old style services are more or less deprecated for new API's and only valid under certain circumstances. But of course that shouldn't be reflected in such a wizard.


However your propositions are interesting: this could be very useful to manage
XSL filters, or generate the package for an add-on. This simply takes a lot of
time that I do not have for the moment. School will begin after the OOoCon2005
and I'll have much less time (even tought I want to spare some times with
girlfriend (I don't know how to say fiancée in english :-())


To continue your effort, it would be nice to have the same for C++ or Python
with KDevelop ! Some volunteers ?


This can even be done with Eclipse: I just do not have much time to understand
the C++ and Python plugins. The last one is not as good as the Java or C++ one,
however, it could helps.

From my point of view we should focus on the most important languages and that are for me C++ and Java. But of course if there are volunteers ;-)

Juergen


If somebody wants to help me, it would be welcome too ;-)

Thanks for your help,
Cedric

---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to