OpenOffice.org SDK Released

Jules V.D. writes "The OpenOffice.org group on Friday announced a kit that lets programmers build new modules for open-source alternatives to the Microsoft Office suite.This new SDK is an add-on for OpenOffice.org 1.0.2. It provides the necessary tools and documentation for programming the OpenOffice.org APIs and creating your own extensions (UNO components) for OpenOffice.org."The highlight of this SDK is the new Developer's Guide. This comprehensive guide provides, in 900 pages, a detailed description of the OpenOffice.org API concepts, the OpenOffice.org UNO component model and how to use the API in the context of the different application areas.""

Comments

A good step

[Anonymous Coward]

I think one of the strong reasons why we have Microsoft's dominance on Office programs is the add-on programs that take advantage of APIs provided in the office. So this is a good step, although I am very suspicious about how strong these APIs are compared to MS Office.

Re:A good step

[anonymous loser]

I agree, it is a good step, but there are still some *major* technical barriers that must be overcome before this will really be accepted as an alternative in business applications.

The main problem as I see it is that MS Office products support a COM automation API right out of the box. Now, I know a lot of folks may not think this is such a big deal, and the OpenOffice folks do provide a lot of similar functionality, but let me tell you why COM support is so important:

There are literally thousands upon thousands of business applications that already exist, written in VB and MS active scripting languages (VBScript, JScript, etc.) that depend on being able to access these other applications pretty much natively.

And, if the API isn't *exactly* the same, no company that depends on MS Office's API for business apps will be willing to spend that kind of development money just to make things the work same as they already do without OpenOffice.

The only chance I see (without OpenOffice implementing a perfect mirror of the MS Office API, and making it work natively with COM) is if somehow OpenOffice offered some amazing new functionality that a business couldn't possibly achieve using MS Office. Given MS's uncanny ability to steal good ideas and integrate them into their own products, that doesn't seem very likely to me.

The APIs are pretty cool

[Krischi]

I've played around with an Alpha version of the SDK in October, and it was pretty nice. It is hard to get your head around some concepts, because the whole SDK is kind of baroque, just like OOo itself, but from my limited experience, it is very powerful.

I built a bridge for the Lua scripting language on top of the Java UNO bridge and used it to script 2D animations for a movie that I had to create for my research. I used OOo Draw to specify the animated elements, and traced out their paths via other elements and object prperties.

The scripts inspected the objects and their properties, animated them accordingly in an OOo Draw canvas, and saved the frames to the disk. All in all, it took me about a week to get this to work; time that I consider well-invested.

Re:How about porting it kde now.

[IamTheRealMike]

How about .... no.

OpenOffice is enormous. The code is mindboggling. It has its own portable runtime, its own object model, its own widget toolkit. It's like Mozilla.

You can't "port" it to KDE, any more than you could port it to GTK/GNOME. What Ximian have been doing lately is simply touching up the edges, making it use the same font/colors as GTK, use GNOME artwork etc, but it's not a "port".

[soapbox]The original KDE vision of producing an integrated desktop through making kickass APIs that everybody would use was a cute one, but ultimately short sighted - your average Linux desktop is a mishmash of different platforms and toolkits, KDE, GNOME, OpenOffice, Mozilla, Wine - there's no way all this sofware can be ported to KDE, so the only solution is to eliminate the idea of KDE/GNOME as a platform and become based entirely on standards, with KDE merely providing an implementation via C++ APIs.[/soapbox].