As some of my fellow developers at Novell have already explained it: we currently had a week of Innovation time. As I was on holiday during the official hack week time, I had it last week... and worked on the ooeclipse integration. This was an occasion to make some old ideas realized. The sources are already committed and push to the git repository.

Description.xml really simple edition

First of all, and it took most of the time to do, I have extended the package.properties editor to also edit the description.xml file. An Overview page will now help the users to configure the most important informations of the extension. There are still a few things which could be improved:

• there is currently field to select the extension icons.
• the description files selection is still present in the old Content page of the editor but is not synchronized with the Overview page at all.
• the save doesn't work when you have switched to the description.xml source page. This is clearly a bug... still too tricky to have been found and fixed in the week.

Here is a screenshot of the Overview page for the description.xml file of my COOoder extension.

Description.xml edition page

Unit test for the OS tests

I had a lot of complaints about some versions of OOo not working with the plugin, mostly macosx versions. The fact is that I don't have all those OS running at home... and then couldn't test them all. I have hacked this part of the code to be able to run some basic automatic tests to check the verifications done on OOo's structure for each of the supported OS. This is implemented by this JUnit test case:

http://cgit.freedesktop.org/ooo-build/contrib/ooeclipse/tree/core/source/org/openoffice/ide/eclipse/core/unittests/OOoTest.java

Testing the different files that are checked for every OOo install will now be easy. Even if this is not a really important news for the users, this is one for me (and other potential developers) to help the maintainance.

A first C++ support

Java was the only extension language supported by the ooeclipse, this will no longer be true. Even if the C++ support is currently really basic, there is one. The main problem developing the C++ plugin is to use the CDT API: the documentation is really seldom and often old. On top of that the sources are linked linked to the plugin by default in Eclipse: then exploring the CDT sources is quite a nightmare.

Here is a small screenshot of the first C++ OOo extension project structure:

UNO C++ project structure

What is currently working:

• The C++ project is created with the includes and source folders defined
• The tool chain is working up to the cppumaker run (included)
• The service's implementation skeleton is generated

Among the points to complete can be found:

• The code build and package generation isn't working. There may be some generic Makefile to create, or to use Eclipse CDT features.
• The three registration methods will have to gather all the ones created by the uno-skeletonmaker for all the implementations.