KOffice, the KDE office suite, has always stood behind the OpenDocument Format (ODF) as an industry standard. Now with KOffice 2.0 around the corner, with OpenOffice.org quickly becoming a new leader, and with Microsoft to release its own so-called "open" format, ODF and the interoperability that it promises is more important than ever. The KOffice developers will meet in Berlin during the weekend of May 12th-13th to do as much ODF-centered development as possible. Read more to find out what this can mean for KDE at large.

First a little background. In May 2006 the OASIS Open Document Format for Office Applications (the OpenDocument Format) was voted an ISO standard for office documents. KOffice is one of the initiators of the format, and has its own representative on the OASIS technical committee: David Faure. Since KOffice 1.5, OpenDocument has been the default file format, making it the first office suite in the world to implement the format.

During the last year the KOffice developers have been working on the next generation of KOffice, based on Qt and kdelibs version 4. This will bring new qualities to KOffice, like improved text layout, better embedding of new data types, and also support for new platforms like Windows and MacOS X.

With a new platform (qt4, kdelibs4) comes new possibilities. The KOffice architecture has changed much since the 1.x days and therefore much of the old code has to be reimplemented. The KOffice developers will gather at the KDAB offices in Berlin during the weekend May 12th-13th to design the new ODF infrastructure and also implement as much of it as possible during 2 frantic days.

That is not all, however. Many people in KDE recognize the importance of ODF as a standard that ensures interoperability. The meeting will also include the participation of Aaron Seigo, who will represent kdelibs and other parts of KDE. The idea is to create a library like kdepimlibs (perhaps to be named kdedoclibs) that will be usable by all KDE applications to create and view ODF files.

KOffice will always be a prime ODF editor suite, but there is no reason to believe that other applications won't need to create or view simple ODF documents. Tobias König of okular will also be present at the meeting to present his view on what is needed to implement effective ODF support in okular. Other potential uses are the creation of tables or diagrams from kde-edu applications, invoices from Kraft (see last Akademy presentations), and so on. There is no end to the potential possibilities.

This OpenDocument library will not be ready for KDE 4.0, but a preliminary goal is to finish the design and also have the first version of it ready for KOffice 2.1 and KDE 4.1. We will produce reports on the progress during and after the meeting so that the KDE community is kept well informed about the progress. We believe that this initiative will help make KDE the premier desktop for business and school use and also produce a strong platform for years of exciting future development.

You are looking at the wrong binary. The KWord-specific code will be found in the library pointed at by /usr/lib/libkwordprivate.so. In my case, this is about 2.2MB

I don't think the original comment was thought through properly. All applications provide a certain amount of unique functionality and that code is not shared with the rest of the system. However, where the authors can identify functionality that is common to multiple applications, that code can be placed in a shared library. This is what already happens with the KOffice, KDE, Qt libraries and others.

To see a full rundown, run "ldd /usr/lib/libkwordprivate.so"

A quick glance at the output shows that shared functionality includes, amongst other things, and in addition to the Qt/KDE foundations:

KOffice 2 goes somewhat further through the "flake" library, which provides various "shapes" ( text containers , Krita images , spreadsheets , videos , vector graphics ) and associated tools to manipulate them in dynamically loadable plugins which can then by used by, I think, all KOffice applications.

Uh.. I was looking at the right binary - I think was just being somewhat more pedantic about the comment that the functionality wasn't in dynamically loaded libraries. libkwordprivate is still a dynamically loaded library - but as the name suggests, the API isn't public.

I think my point was that moving things into dlls (.so files, then) is required, but not sufficient. It's also necessary for that API to be public. Hence the meeting to discuss it.

A common and open file format for project planning applications is something that has been under discussion for years, but the task is big enough and the pool of developers working on such applications small enough that there have not yet appeared any concrete and implementable results.

As for the name: KOffice is getting quite a bit of name recognition. It would be a bit of a waste to lose that through a rename.

Because the logic behind the naming scheme of puting a K before any application who use KDElibs is a nosens for me as a user, because i see applications more important then kde then gnome then even linux, because we need to be more open to other kind of users, who perhaps see this K every where as just stupid, because gnome vs kde war is over. And because we care more about software features then the underlaying technology and toolkit.

I personaly like Koffice as a name, because it make me feel like coffe (sss) which is, as far as I know, something at the basement of office work :)

On the other hand, I don't think that knames are so bad.
some of them are just good (kontact, konqueror, kaffeine, kooka, krita ...)
some K are not so great, as in akregator, but don't feel bat either.
and for the kmail, kplato ... I like them because such weird names make me think "ok, this is an app for KDE, it may be well integrated into my desktop, fast loading, and good looking". For me, it is important, and I was quite disapointed when I tried to install Kino, and apt asked for hundreds of Mbyte of gtk depedencies.

finaly, take a look at other vendors. Apple as it's "i-suite" whit ipod, itunes, iphoto ..., and I don't see people saying that's stupid.
Microsoft as it's MS-things and Windows-things, and nobody complaign ( OK, they often skip the ms or window part and will say open this doc in office, or read this video in media player. but you could say, open this planing file in the kde planig tool, this document in the word processor, and forget the K at the begining of the name )

Devs, if you can't figure out a good name, go for a KWhatMyAppDo, even if not good sounding, it's good understanding.

The name of a piece of software has a few purposes : tell what the software does, where it comes from, and sound nice / catchy. I wont discuss that last point, as it is strictly subjective, but here are a few examples :

Kopete, K3b, Kross, Kate... Well at least you know it's using the KDE framework.

Akonadi, Avahi, Strigi, Dolphin, Plasma... Yeah, right.

Phonon, Decibel... My first guess would be a VoIP app ("phone"), and a sound framework.

It's hard to find a good name. But the current trend (not only in KDE) to use cool names that convey no information is annoying at best, and quite a mistake IMHO. The "KWhatMyAppDo" names are really not that bad.

yeah! I *still* can't remember which flashy name is for which part of kde4... decibel? I keep thinking it's something to do with sound, not... messaging or whatever. plasma? I can't remember what that does at all right now.
the k-names may not be thought up by some fancy marketing team, but they can be *understood*. when I'm trying to find an app for some new thing (like, say, voip) I *like* being able to skim through a list of packages and single out the ones with a K as being the first choices to test. sure, some of them seem silly... but in a way, that just makes them more rememberable.

What I was saying is that, not as you do, I don't dislike Knames, that they are useful, and to prove it right, I gave an example from another trend.

I _can_ understand some people don't like strange sounding names.
But I do like them, _personaly_.

So, which is beter or worse ? Depends on your feeling. We will never agree on that, but I respect your view.

If you whant apps to get cool names, fork the KDE project and rename things as you whant ;-) or you could just take renaming contest ( for instance, I'm proud being one of the Mailody name fathers (as name can have two fathers and no mother) I think it's a good name :)

But don't forget, it may be bad to change the name of a well established software. User not knowing where to go, feeling laid off, when A just became B (and much cooler :)

* We'd better wait to see if Sun's attempt to merge odf and the Chinese format go anywhere.
* There are already a few Chinese office suites that seem fairly complete
* Volunteers interested in this file format need to start working on it. Because, basically everyone on the KOffice team is already spending every ounce of effort they have to spare on KOffice.

Just to make clear; KOffice already supports almost all alive languages and writing systems. Notable exceptions are top-to-bottom writing systems, but the font-layout meeting in aKademy later this year is aimed at that, and KOffice will automatically benefit from that.

So, we don't need support for this new standard in order to support the Chinese language or Chinese users. KOffice already works fine for Chinese (and Japanse and lots of other) users.