As well as the official talks at FOSDEM we will also be hosting 5 talks in the KDE developers room. The KDE FOSDEM team interviewed the speakers to get some background. The first interview is with Raphael Langerhorst whose talk is titled "KOffice - Desktop Integration and Workflow Automation".

Raphael Langerhorst with his Nephew

Please introduce yourself and your role in KDE

I was born in 1983 and I live in Austria, somewhere between Linz, Salzburg and Passau (Germany) in the countryside; I am also a vegan (strict vegetarian) from birth on. The quiet place we have at home is very precious to me and I enjoy it a lot - sitting in the garden or in the woods, reading books or... working with my laptop.

We got our first computer when I was 6 years old, a 286. Currently I'm studying IT in Wels, after having spent 5 years on an electrical engineering school (with "Matura") and doing my national service at the Red Cross. During the technical school we learned C, C++ and Java. I also started to work on a couple of projects during this time.

Well, KDE development started with a patch for KSysGuard in December 2003. Then I saw the summary about KOffice from the Kastle meeting. It mentioned the move to the OASIS Open Document format. Seeing the compatibility between KOffice and OOo in the near future caught my interest. So I joined the KOffice mailing lists to check the progress of this "feature". Since then I sent various patches to the mailing list (KSpread, documentation, ...) and got a CVS account in July 2004 I think. I never had much time left for KOffice though, which makes me feel quite sad since I'm probably one of those who wouldn't mind full-time KOffice development.

When I have time for KOffice I spend it on bug hunting and documentation. In the near future (depending on available time) I might do more QA (Quality Assurance) work for KOffice and even promotion work - I just started as a KDE trainer for one of the larger training institutes in Austria.

I also play the piano and the violin, which I enjoy a lot.

What is the current state of KOffice?

Getting close to the 1.4 release! But there is still much to do (see next question). The current state is a stable 1.3 version of KOffice which had been released a year ago and had already its fifth minor release.

Today KOffice offers a stable office suite for the standard components. There are a few rough edges left though, which are being worked on of course. KOffice is lightweight and thus performs very well even on old hardware. Still it brings lots of features and good KDE integration. In particular the KDE integration is one of its greatest strength, which is vital for business environments.

For home users KOffice is an easy to use, lightweight office suite for daily work.

What have been some of the recent developments in KOffice?

Many smaller improvements have been made since KOffice 1.3. The main focus since the last release has been the implementation of the OASIS Open Document file format. Krita and Kexi are also improving fast and might be included in the next release.

KPresenter has recently got master pages support. There were also some design improvements of KSpread during the last months, and more radical changes are planned after KOffice 1.4.

I think that the most important features for the near future are the OASIS file format support and the additional KOffice components, Krita and Kexi. All this could already happen for the 1.4 release, but there is still work to do.

And recently David Faure became the KOffice Release Manager again.

Kexi has a Windows version available, do you think KDE applications should be ported to Windows and are we likely to see this happen to other applications?

In fact there were a few people talking about creating a native KDE on Windows port and some work is already done.

Whether applications should be ported to Windows or not depends on the point of view. Windows is a rather different platform than POSIX which makes porting not too easy. A lot of opinions have already been expressed. I just want to add to it that the developers should care for clean KDE code. I personally don't want to see it happen that larger code portions are changed just to fit on Windows. I would rather prefer to build on POSIX compliant extensions to Windows (Microsoft has some available!!) and make these a requirement for KDE. This would surely result in less dirty code AND in better operating system standard compliance.

Some more individual applications will likely be ported, but I don't think that KDE will be ported completely in the near future.

How many people are currently working on KOffice

Well, there is Krita, Kexi and KPlato, which are more independent and even have their own mailing lists.

All together there are about 15 people working on KOffice. 1 for KPlato, around 4 working on Krita and about the same for Kexi. Then there are 3 to 5 developers improving the older KOffice applications like KWord, KSpread, KPresenter and Kivio. Sadly Karbon14 and Kugar are not well maintained because of lack of developers. Other smaller parts like the KOffice Workspace or KFormula also have no particular maintainer. Two or three people are working on documentation. Additional help is of course always welcome and appreciated.

What is the current roadmap for KOffice and when will we see the promised native OASIS file formats?

There are no particular dates set for releases yet, but so far we have decided to release KOffice 1.4 with KDE3/Qt3 early this year. The next major release will be KOffice 2.0 which will build on KDE4/Qt4.

Much work has been put into the OASIS Open Document format and most of the implementation is done. But it will be a close race with the 1.4 release, also because the file format really needs much testing before we can switch to it as native format. So far the OASIS file format is only for Karbon14, KWord, KSpread, KPresenter and KFormula since OOo does not have equivalent components of the other KOffice components. Thus there has not been much effort (or human resource) to add specifications for such applications. It might be possible that KPlato comes up with an OASIS specification for project management though.

Both Kexi and Krita will be included in KOffice 1.4. KPlato will probably be included with KOffice 2.0.

When this has been accomplished KOffice is a really complete office suite, having integrating components for text processing, spreadsheets, presentations, flow charts, pixmap and vector graphics, report generation, database frontend and project management as well as formula editing and a chart engine. Including a common workspace!

How do you see the relation between OpenOffice.org and KOffice?

First, I don't see a competition between these office suites. Both have their strengths and are suitable for different situations. A very important advantage of both office suites is their common file format in the near future. This will make seamless document exchange possible and it won't matter which office suite is in use.

A big advantage of KOffice is its KDE base, which makes it more lightweight and integrated. OOo brings its own framework which makes the codebase bigger and harder to maintain, but it is necessary to be cross platform. And this is what makes OOo more suitable in mixed environments - OOo builds the bridge between Windows and Linux/Unix whereas KOffice might be a better choice in pure KDE environments. OOo is also a suitable bridge between many legacy file formats and the OASIS Open Document format.

Seen this way OpenOffice.org and KOffice really complement each other rather than compete.

KOffice is missing a logo, do you have any suggestions?

Yes, actually. Recently there had been some KDE Look contests for various applications that had no logo. I think we could launch such a contest to have a logo ready for KOffice 1.4. The results produced in previous contests are really good quality.

I think the OSS community should now be in position to provide an audio [or even video] interview by default. We have OGG and many players to choose from. I'd love to hear these wonderful people talk. What do the rest think?

If I manage to get the time needed I will work on training articles etc for KOffice in the near future. I also plan to write something for KOffice development, but that will have to wait until KOffice 2.0 since technology (Qt4/KDE4) will bring some changes - and honestly, I still need to learn more about KOffice before I can write really good development tutorials.

> I want to chuck out MS Excel which i run through crossover if i can find this functionality in kspread. Openoffice takes ages to load on my poor student system.

I've heard of people using this combo for analysis:

DB -> Octave -> gnuplot

This flow is more appropriate than a spreadsheet for large volumes of data. But, samples in student exercises tend to be relatively small. (If wanted, you could even use gnuplot for student exercises by placing the data in a text file[1]. This isn't the friendliest method, but it is still more powerful than what could be accomplished using a spreadsheet.)

Deciding on how many people really work on the core/older applications was not really easy. I mainly based this on the commit logs during the last couple of weeks.

In total I think there are about 10 people contributing to these applications. But most of the time some of the contributors are just not active. So if we take one point in time we might find about 3 to 5 people that are currently very actively working on KOffice. And... which surprises me day after day... these few people get actually quite some stuff done, it's really amazing (IMO).

Watch the commit logs for some time, you will be surprised how KOffice evolves - DESPITE the few numbers of developers. Of course things would go even faster if there were more such heroes (as I am starting to call them) - everyone is invited.

And... I'm using KOffice every day, I don't even have any other office suite installed. I really came to love it.

well, more help would be nice, but its already a great office suit. I use it for all my daily work, and it does that very well. its faster than OO.o, and has all features I need. Also the KDE integration (KIO-slaves!) is great.

I really really want a new kind of word processor. I truly loathe the MS Word type of word processor. I started writing a thesis using KWord a few months back, but switched to OOWriter since I couldn't input Japanese into KWord. The thesis is finished now, but it was incredibly frustrating to use oowriter. Just like MS Word, it always does things automatically, and half of the time it's not what I want and I just can't get it to do the right thing. I don't think I've ever felt so sympathetic with people actually punching their screens as when I tried to get oowriter to do what I wanted.

I tried KLyx too, which seemed like a good solution. No Japanese support there either, so I had to give it up. And even if I had gotten that to work, it would still have needed a plugin for full Japanese support (furigana).

I propose a new application: Edit your document directly through it's "language", while having the result updated in real time, as well as WYSIWYGically moving around things using your mouse. Not insanely complicated like lyx (with bizzarre font problems, nonfunctional plugins etc etc), not incredibly stupid like MS Word. And with asian language support; hell, even vertical writing.

I'm considering getting familiar with QT 4 and starting an app like this.

Who's with me? ;) (yeah I know, I'll let you know when I have some code to show)

In the future Quanta may be usable to do something like this. You can create a new XML-based language for word processing already, so you can write in the "native" language. We plan to introduce:
- automatic (periodic or as you type) updating of the preview
- support XML in the preview, rendered through an style sheet

Navigating in the rendered version might be a challenging thing though. The katepart editor used in Quanta already supports japanese text introduction, and support for bidi (and I don't know, maybe vertical typing?) is planned as well.
Of course, this will not happen before 4.0.

Input Method (IM) for Asian characters was recently added to KOffice HEAD, meaning it will be available in KOffice 1.4.

You can even write from right to left... and you CAN do vertical text ;) (just rotate the frame).

If there are things you would like to see implemented in KOffice it would be great to join KOffice rather than beginning a new application. But I know this is/was well intended :) At least sending us a wishlist about ideas helps already.

LyX's WYSIWYM approach is great, in theory, but got on my nerves for it's lack of seamless support for the ever expanding LaTeX class macros and styles.

I use Kile. It works great. It automates a lot of LaTeX and comparing the code between LyX and Kile I prefer being able to refine my LaTeX to reduce any bloat or dealing with under underfull \vbox or overfull \vbox errors.

I never had issues being American for localization issues but I'd imagine the lack of broad internationalization support would be annoying.

I'm going to revisit LyX 1.4 when it's completed. Hopefully, they will have full Memoir class support and all the other classes Wilson develops. I highly doubt it, but I'll still check on its progress, over time.

Wordperfect has done this for years. It works well and many people prefer being able to see the control codes. It gets unwieldy with very complex documents though.

Every time I've used MSWord I got frustrated and wonder why it has become the standard. I don't think it's fair to compare KWord with MSWord. The don't work the same way, even if the same formatting choices are available.

If KOffice is using OASIS as it's underlying format, how hard would it be to extract out the OO code that does import/export to take advantage of it?
That would make KOffice the ultimate linux crossover app IF it was lightweight, stable and could import Office docs.

Importers/exporters in KOffice are pretty much separated from the actual application logic. This is not at all the case with importers/exporters in OpenOffice (last time I checked) where you'd first separate the code clean before even thinging of taking some of it into KOffice. The necessary effort is better spent directly at KOffice's importers/exporters.