Skip to content

KDE and OpenOffice

Monday, 16 October 2000  |  Numanee

Sun Microsystems, probably best known at the KDE end of the spectrum for their influential paper on local vs distributed computing, recently open-sourced StarOffice, making it freely available to KDE as well as other projects. What impact will this have on KDE and KOffice? Ideally, even though OpenOffice is technically a competitor to KOffice (Sun apparently denies this) and despite the naysayers, OpenOffice will be of sizable benefit to KDE. Read on for a few of my initial thoughts on the matter.

While OpenOffice is certainly a huge contribution to the free software community, it will likely take a certain amount of effort to integrate it well into today's free desktops[1]. Judging by the technical overview, OpenOffice contains and is based on a huge chunk of inhouse technology, implying that there are ways to go before a port to a free desktop environment that is compatible with all the goals of the project is complete. There is no immediate need for such a rewrite, of course, as OpenOffice is already useful and porting existing working code will be a significant task with little or no actual benefit for the applications proper. In fact, a reckless rewrite ala Mozilla might be dangerous from a market perspective, so caution is advised. In the interim, OpenOffice appears slick and polished enough to pass for a KDE1 application and that could be sufficient for now.

In contrast, KOffice, was built from the ground up for KDE[2], and is fully integrated with native KDE component and related technologies. It may actually be easier to import useful code and technology from OpenOffice to KOffice than to rewrite OpenOffice. In fact, Shaheed Haque, one of our filter experts, lost no time at all in investigating the Microsoft Word filter code. At first glance it appears it will be very useful as a basis for improving KOffice's own filter code. Almost just as promptly, Matthias Elter discovered a set of free high quality TrueType fonts that could come in useful for KDE as a whole. Time will tell how much more technology can be imported, and whether KDE can make good use of all the work that has gone into or will go into OpenOffice.

At the same time, OpenOffice could certainly borrow technology from KOffice. For example, they could consider adopting (and possibly refine in collaboration) the KOffice formats which already use XML and which solve some of the same issues that OpenOffice.org is currently attempting to address. This is a wonderful opportunity for collaboration between OpenOffice.org and the KOffice/KDE community.

In conclusion, while OpenOffice is a mature product, it has a major rewrite and redesign in view if it is to compete on the Unix desktop. KOffice, on the other hand, is already fully integrated with one of the major free Unix desktops but is relatively new with an imminent first public release. Some may argue that one has the advantage over the other in the context of the Unix desktop, but ideally, if this plays out for the best, both KOffice and OpenOffice will see huge and mutual benefits, and both will prosper. Meanwhile, the KOffice project could certainly use your help, contributions and input.

Opinions?

[1] One of the stated and hyped goals of the OpenOffice project is a port to GTK+/GNOME technology.

[2] While KOffice does use KDE technology, one is not forced to use the desktop environment to run KOffice.

Comments:

Re: It's going to be interesting - John Califf - 2000-10-16

This is a very interesting comment. It would help for someone to follow up who knows more about the file formats of OpenOffice (someone from Sun) or from KOffice like Shaheed. I'm a fairly new KOffice developer but I'm not familiar with all the KOffice file formats yet. Several points need to be clarified and several questions are raised. <p> *Actually the file format (DTD) does or should define or at least influence how the application works if both are designed well. The app should be build around the file format if it is to work efficiently, because the document structure is defined by the native file format anyway, at least in KOffice. <p> *KOffice has file formats for all its major components. You say that OpenOffice also has DTDs for XML file formats. Have these already been implemented in the current Star Office or are they just proposals for the new version? If they aren't set in stone yet then perhaps there is room for give and take between KOffice and OpenOffice in defining common or more compatible file formats for the different document types. It should not just be a matter of KOffice adapting to what OpenOffice proposes. Give and take should work both ways. <p> *At the very worst, even if the file formats are different, the fact that both use XML and are open makes translation between them fairly easy, much easier than translating betweeen MS Office formats and KOffice. <p> *Finally, regardless of differences between the file formats and office suites, the success of OpenOffice can only help KOffice and visa versa, at least in the near future. More users of Linux and other free unix systems means more users for both office suites, and less of a lock on file formats by closed source vendors like Microsoft.

Re: KDE and OpenOffice - Kristian Köhntopp - 2000-10-16

There is nothing wrong with that. It's just ironic, that's all. As pointed out further above in this discussion, the irony goes even further. Star Office is a really large chunk of code. Much of this code is not really related to an office package, such as the operating system independent windowing subsystem in their MDI window, many widgets that would be useful in other applications, font and printer handling, HTML viewing and processing, a script interpreter and an interface to it and the like. Such code does not actually belong into an application, but into a desktop environment. That way it becomes useful not only to a single application, but to all applications being written for that desktop environment. The Open Office project and Gnome can now choose to incorporate this code into their desktop, turning Gnome essentially into KDE (see below). Or they choose to drop this code from Open Office, and importing the related Gnome components into Open Office, leading into the murky area of C/C++ code integration. Or they can choose to integrate Open Office and Gnome only superficially, duplicating essential parts of their infrastructure and bloating a project even more that is already suffering enormously from bloat. If I remember correctly, back when Kalle & Co were still working at StarDiv there was some discussion in the german Linux newsgroups about the major fault of Star Office. That fault was that Star Office tried to duplicate large parts of what makes up a desktop environment, but did so inside a single application. That was a pity, as this code became largely inaccessible to other applications. Star had an offer selling their multiplatform windowing toolkit as a commercial product, but it was even less popular as Qt at that time. Star Office had to carry around all this code in order to be useful on any Unix system, as there was no support for large desktop applications at that time on such systems - there was neither KDE nor Gnome, just Motif or even worse toolkits. Looking at the SO code tells you very precisely what the advantage of the Windows API over Motif was for application developers at that point in time. A number of the people working at Star Division at that time became the core of the KDE project, and many lessons they learned doing Star Office influenced their design of vital parts of what is now KDE. Of course KDE is now much larger than that and the technologies making up KDE now have partially transcended what makes up Star Office, so the analogy is stretched pretty far. But: If you take apart Star Office and integrate what is useful in it into any Unix desktop project, you end up with something that would be very hard to distinguish from KDE now. Integrating Star Office into Gnome will turn Gnome into KDE, and that /is/ ironic.