The KDE Project today announced the release of KOffice version 2.0 Alpha 7, a technology preview of the upcoming version 2.0. This version adds a lot of polish, some new features in Kexi and KPresenter and especially better support for the OpenDocument format. It is clear that the release of KOffice 2.0 with all the new technologies it brings is drawing nearer.

This is mainly a technology preview for those that are interested in the new ideas and technologies of the KOffice 2 series.

The Alpha 7 release is a work in progress. This release introduces improvements in almost all the components as well as in the common infrastructure. All the applications saw big changes, both bugfixes and new features.

Ongoing Polish

The release notes for Alpha 6 noted the addition of snap-guides that will guide the user when he or she is placing objects near other objects in any direction, Alpha 7 adds a bounding-box snapping option for even more powerful snapping options. This release has also added the option for users to configure shape-shadows in the form of a new dock widget.

Report Generator for Kexi

There is a whole new set of features in Kexi, the most important of which is a new report generator. This allows the user to create a document based on the data in the database with features like charting and scripting.

New Features in Krita

Krita has received a lot of attention e.g. general polish and bugfixing. Krita has additionally received a new plugin type which will allow both KOffice developers as well as 3rd party developers to create new pixel-generator filters, such as clouds or fractal generators.

Developer Focus on KPresenter

The KOffice developers decided to focus their efforts to make KPresenter an application that will be released in the 2.0 suite. This has given KPresenter a lot of page-effects in this release, but has managed to do more work on master page editing as well. Much of the work on the KOffice libraries have been specially selected because it benefits KPresenter in particular.

Improved OpenDocument Support

This release is the first to see some results of the OpenDocument Format testsuite being imported into KOffice. The testsuite exists from a lot of little documents that each show one feature in ODF. Automated testing of loading those documents will allow developers to keep on working on the code without fear of breaking the already working code. This is known as regression testing.

In this release already 23 tests are added into KOffice and the results are visible in much better loading of text documents in KWord. KWord is also one of the target applications for 2.0, and NLNet has sponsored a developer working on that application.

KOffice 2 is still under heavy development. It is not meant as something
to be used for any real work and can crash at any point. However, here are
some of the highlights of the upcoming KOffice 2 series. Note that not all
of the new technologies will be fully implemented in the first release, 2.0.0.

> Is it safe to expect a Mac and Windows build the day that 2.0 launches?

This release already makes sure that everything builds just fine on Windows, the mac version build great for at least a year already (last year a Summer of code student did his koffice2 project on the mac).

So, while there is no guarantees the chance is pretty good that indeed the day we launch 2.0 it will be cross-platform.
The main problem is that we hardly have anyone compiling/running koffice apps on Windows. Just a couple of awesome kde-devs that make all of kde compile on Windows.

>Further down the chain, but important to many, how will MS binary format import/export compare to KOffice 1.x and OOo?

I'm working on the KWord filter for the summer of code (porting the filter to ODF and working on graphics in libwv2). I'm not sure how much of my code will be in KOffice 2.0, but it's being worked on. So, the filter should be improving with respect to KOffice 1.x, but we've got a ways to go to catch up with OOo.

Whoa, sorry, I guess I wasn't clear. My work is definitely in the 2.0 codebase (in the msword-odf branch); I just wasn't sure if my work would be done in time for the 2.0 release. I guess it probably will be, if 2.0 isn't released until August or later.

There are actually relatively few Free software apps in the spaces KOffice apps exist in. Kexi and Krita are two really good examples, but even KWord, KPresenter and KSpread only have a couple Free software companions each.

It's nothing like the situation with text editors or media players.

Also keep in mind that KOffice predates the other Free software apps in this space, with the exception of the "old school" apps that can be used for similar tasks (e.g. latex)

I still use openoffice too. But im not a happy user. It does not integrate well with my desktop, takes a long time to load. I use it for the lack of better alternates. The day koffice can match i'll make the switch 100%.

Personally, I find that Krita is often a better tool for my graphics tasks than GIMP. For instance, I made a document management application mockup (http://syntaktisk.dk/grphcs/docuzilla-mock.png) a while ago, and I found that using Krita made it much easier. I make quite a few graphics buttons, and that is nice with Krita.

I think that if there's one thing missing in the free software desktop so as to be ready for the average user is a good, full-featured office suite. KDE4/QT4 technologies are just awesome, so KOffice has the possibility to become the best office suite ever!

OpenOffice doesn't seem capable of ever growing beyond the 'copy MS Office 97' paradigm. It's codebase is too complex and dazzling to attract new developers, hence innovation is unlikely. KOffice, on the other hand, has a strong base to build upon, and is already doing a lot of interesting things. As I'm a strong believer in innovation as the way forward for FOSS, the chances of KOffice 'saving' the office workspace for FOSS are imho much larger than for OO.o.

While I agree with you in theory, judging by the always existing lack of developers in KOffice, the simplicity and structure of it's code base (at least, relative to OO.o) does not really help in practice to attract new developers. Or am I off in this respect?

Besides the problem is really that openoffice is an artificial effort right now, marketed by Sun.

Koffice is MUCH more close to the community.

The only problem is that I cant code in C++ (and I wont. I use ruby for all my work). :)

The best solution would be to be as generic as possible and allow people to write plugins etc.. in the language they use. I really have no need for java, c++ or whatever anymore, and I dont want to waste time just for coding in C++ (because I know, I wouldnt code in C++ anyway.).

Well actually with the Kross binding, you can write features in Ruby, Python and JavaScript, either scripts or even dockers. I don't know what you are intersted in doing, but you can do stuff in ruby, and we would really love to have some inputs on the bindings.

And especially word processors, there are like openoffice (i hate it...) abiword (the best, but has not enough features) and koffice (i think koffice will become the best word processor in the future, it has a smarter developer base. Openoffice somewhat sucks, and is so java centric - it should be more user centric.)

While witting a book I started off in OpenOffice, then moved to Kword, both applications left me dual booting windows simply so I could use office without the need for wine. It's nice to build applications to try and get people away from office, but when you use those applications and then they screw up your work when given to the publisher, it is not worth the time and hassle. I personally do not see a time when I will move back to either, and have become my next novel using Microsoft Word

On the other hand, when someone I knew had to write a book, and did it in MS Word, and noticed she had only 70 pages out of about 500 left after a save, I had to take a three hour train journey to help her out. In the end, I only got the project to the printer through Open Office.

In other words, assuming that Word won't screw you is a really sure-fire way to get screwed.

From the website:
"Important features not included:
- Resource leveling. Resources are just allocated to the requested task even when allready booked to other task(s). The resulting conflict must be resolved manually by adding task links or constraints to avoid parallel scheduling of the tasks.
- Network view.
- In general: Project execution and follow up."

Oh, I'd love some more features in Kplato. From what I can see Kplato is alone in the project planning field.
Improve this and add hooks to kontact and other applications and you've got yourself a "killer app" imho.

It's interesting to see the KOffice developers focus on some applications to get them out. FOSS development is rarely good at that: focussing on something because it's good for the project, instead of focussing on new & cool stuff. I think it's saying something good about the KOffice dev's ;-)

But of course, many of us already know what a responsible bunch they are...

I think any release of the KOffice be it Alpha, Beta or Final is an astronomical achievement, also if you take the number of KOffice developers into consideration.
As a user I've known Koffice since KDE was in it's infancy; and believe me, with the means at it's disposal it has come a hell of a long way.
These developers must be working pretty hard. At the same time they are introducing new technologies into the workspace. To fulfill these visions takes nothing but a lot of guts, a lot of hard work, and above all perseverance. After the next major 2.0 release it would be fantastic to see more developers joining their development team.
It's funny how a lot of people always need to see some end-product before they can actually believe in it. On the one hand I believe it's good to know the status of something; but more then anything I believe projects need people who believe in a vision and can creatively see the goals ahead of them. I have a lot of respect for your work, so it's hats off from me!

But then you are not counting the lines of code of the kdelib and QT that KOffice is making use of.
Please remember that OpenOffice.org isn't just an office suite. It has its own crossplatform toolkit, just like QT but much more uglier and harder to deal with. When you count the lines of code of KOffice you don't put the libs it's using too.

The same stupidity has been done by the Mozilla team. Their browser ain't just a browser, it has its own motherfucking ungodly platform that they are the only one to use (and a handful of crappy, slow programs like Miro and Komodo).

I'd rather say it's OOo's (and Mozilla's) issue that they don't even bother to separate all the crossplatform toolkit stuff instead embedding it with every single app. So KOffice devs shouldn't be shy referring to their low SLOC.

First of all thanks a lot for your work Kde and Koffice teams!
One application, in my opinion that has a lot of space to grow, because there's no rival, or any good FOSS implementation is Kivio.
There's always commercial solutions, but if you choose omnigraffle, you need to stick with MacosX, or if you choose Visio you need to stick with Windows.
But in the FOSS world, the only thing you can get apart from Kivio is Dia and the Openoffice one.

A lot of people need to make diagrams, from companies to students, but Kivio at this moment, seems to have only one developer. (from a IRC talk)
I know everybody is busy this days, I included... but the facto is, if we can get a good FOSS alternative, in a deficient area, we can get a lot of success... Imagine apache web server...

Note: this post is only intended to be a constructive though only. (in case somebody feels offended)

"Note: this post is only intended to be a constructive though only. (in case somebody feels offended)"

Sure, I think most people would agree with you. The difficulty is, though: what are we going to do about it? Lots of people are pointing out problems, but no one seems to be coming up with much-needed solutions.

Indeed, no offense taken :) And we all agree with you, but there isn't much we can do about it. We are trying to find ideas on how to attract new developers, and the new architecture in KOffice2 will allow to bring a lot of improvement to Kivio, better graphics, better text, so the future is bright, but we indeed need more people to make that future.

A nice idea, but hard to implement. Accepting credit cards is expensive. Paypal is the best option, probably, except they're untrustworthy, and you're just as likely to have them freeze your account and money as you are to get anything. (http://paypalsucks.com for tales of woe)

I've seen people post their amazon wishlist or the like, and then you can buy things off there. That might be the easiest option. But not cash.

If you paypal the KDE e.V. money and say it's a donation for KOffice it'll get spend on us :-). We are very fortunate as a project that we fall under the KDE e.V. umbrella: they handle all that kind of thing for us, and we get to spend way more money than we'd be able to spend on developer sprints, conferences and other fun stuff otherway.

(Like, I've just come back from the Libre Graphics Meeting, for which the e.V. sponsored three KOffice developers travel and lodging. I'm going to write up a dot story tonight.)