Swiftly following the latest bugfix release for KOffice 1.5, the KDE Project today announced the release of KOffice 1.6 alpha. This is the first preview release for KOffice 1.6, scheduled for release this October. KOffice is an integrated office suite with more components than any other suite in existence. KOffice 1.6 is mainly a feature release for Krita and Kexi while the new revolutionary KOffice 2.0 is being developed, Read the full announcement and the changelog for more details or read on for the full article.

This release specifically introduces the following highlights:

Lots of new exciting features for Krita and Kexi

Krita and Kexi has gained many new features and enhancements of old features. There are too many to list here, so for more details look in the announcement, orthe complete changelog

OpenDocument Support in KFormula

KFormula has received a great workover. Among the most important changes is
almost complete support for the OpenDocument file format which is now
the default format.

Scripting support in KSpread

KSpread, the spreadsheet program, now supports scripting in Python and Ruby just like Krita and Kexi. This is done through the KOffice scripting engine
Kross.

Of course, there are also fixes for a number of bugs and introduces
a number of lesser features.

This is a technology preview, and will only be available in source format.
The sources can be downloaded from the KDE download servers, and compiled on
any unix machine with kdelibs 3.3 or newer (not 4.0). See the announcement and the source code itself for more details.

The final release of KOffice 1.6 will not only be more polished, but will also contain several features that were not yet finished for this preview. This is a very good time for developers who have wished to contribute to KOffice to come in and have a look around.

We really, really need a small team of dedicated users to do regression testing for KOffice. Regression testing is not something easily automated, and not something developers should do -- because developers know the right path through the application. Ideally, we'd start with a set of regression tests based on existing bug reports augmented by a set of regression tests that cover all features of all KOffice apps, and have real people exercise those tests during the beta's.

I even started writing a web application for that, something like bugzilla but for tests and with statistics about the best tested app, the team that's got the most complete coverage and things like that. I might pick up on that in September.

But even right now, I hope that you'll be among the people who download the alpha's and beta's, test it rigorously and mail your results to the mailing list or put them in bugzilla. Or contact the KOffice hackers on irc about it.

But it is somehow frustrating to test and report problems, if really heavy bugs are not fixed for a long time. One example, which makes kspread unusable with formulas: 114635 The bug is in 1.4.2, 1.5, 1.5.1, 1.5.2
And even bug fix releases of koffice are gone public with such critical things open!
So a kspread user is forced to use other programs (because you can't save your data in a looping application) and will not continue to report bugs in kspread in future.

That's where this team of regression testers is different from ordinary users reporting bugs: their task is to make sure problems are caught before release, and that regressions (where things that used to work don't work anymore) are caught, too. This is an effort to help the developers reach good and dependable releases.

Of course, alpha and beta releases are the places where regressions should be caught. It's more than folly, it's actively malicious to review alpha releases as if they were full releases like Linux Format did with KOffice 1.5 and then to decry the bugginess of applications. The regression testing team should concentrate their work during the beta phase.

(Oh, and from the bug report you mention, it's clear that work is being done on it, it's just that it looks hard to fix. It's not being ignored...)

I wouldn't mind testing KOffice if it is simple enough to put beta version next to a stable one.
I'll explain:
With OpenOffice, for example, you could install both OO-1.1 (stable) and OO-1.9.x (unstable) for the same user, and simply run one or the other. The setting of one version would not affect the other, since they sit in different directory (~/.openoffice-).

Is it that simple with KOffice?
Can you give a brief description of how to do that, and point me to the right web page where it is explaind?

I am running FC5, and usually installing software with yum (i.e. RPMs).
I never used Klick.
How does Klick integrates with Yum?
Can I be sure that the system will stay consistent, (in terms of libraries, path, rpm database, etc. ) if using both Yum and Klick?

Klik doesn't actually install (well other than klik itself, which is really small) anything on your system (everything stays in a .cmg file, which is a compressed file system image). Klik won't interfere with Yum at all.

>>How does Klick integrates with Yum?
I does not.
Klik does not install anything, it fetches the packages from internet and creates a cmg image (comparable to dmg from macosX). To run koffice, simply click on the cmg-image. Klik will mount the image and start the applcation that is inside it. When you close the application, the image will be unmounted.

>> Can I be sure that the system will stay consistent, (in terms of libraries, path, rpm database, etc. ) if using both Yum and Klick?

Yes, if you want to remove an application that was installed with klik, you simply remove the corresponding cmg-image. That's it. Klik does not alter any systemfiles or libraries.
AFAIK klik does not even touch your personal settings (e.g. files in ~/.kde), but creates new ones. So running koffice 1.6 alfa does not in any way interfere with koffice 1.5 that you installed with rpm/yum

But, doesn't klik programs still use the same configuration files than installed versions? If that's the case, running a newer version of an already installed program might change the settings in a way not supported by the installed one.

1. Create a new user.
2. Install the software in the home-directory of the new user.
3. Use kdesu (or sudo to don't get asked for a password) to execute the software installed as another user in the session of the user you are currently
logged in as.

Regression testing is only one part of it. You need defined testcases, synchronised with implementet changes, to do the this kind of testing or otherwise its meaningless.
Regressiontesting from a user standpoint is relatively easy and fast to do. "Real testing" is much harder and time consuming and i would really love ot see a testset that could test the intended functionality of the system. For this there is a need of a tool like Mercury Test Director. Is there any equivalent tool in the Open Source world?
If there is a would certainly volunteer to write testcases and do some more formal testing.

A while ago, it was said that tools to make watercolor painting and other kinf of Painter-like tools was planned, even being developped for Krita. The goal was to differentiate from Gimp in providing such tools aimed at creating content.
All the recent additions seem on the contrary to be around photoshop-like features, closer to what Gimp has to offer (going beyong in places, like CMYK support).
Did the idea of supporting this type of tools was dropped?

I actually have most of a chinese brush simulation done and the beginning of a fun oilpaint brush. But I got kind of burned out after the 1.5 release and didn't do much towards 1.6 or 2.0. Which means it didn't get finished. And Leonardo, an Italian hacker got run over by a car before he could commit his watercolor stuff, and he's been out of action for a couple of months now, although he's expected to come through fine. The watercolor stuff that's already in Krita doesn't want to dry for some reason, and I cannot find the problem, nor can Bart Coppens. And before I got burned out, I was permanently distracted by bug fixing, release management, trying to come up with a shared openraster file format and lots of other things. Cyrille has been working on a Corel Painter style programmable brush, but I don't that that's done either, otherwise it'd be in 1.6.

Krita is really ready for painterly stuff: the core supports any type of colorspace, regularly running filters to simulate drying and all that. Now it just needs to be finished, debugged and included.

Ugh. Just when I thought I had an unlucky day myself I thought I might read some KDE news to cheer me up... Well, that didnt quite work except that
others seem to be even more unlucky.

The internet is somehow a strange place. All those people seem so close but on a bad day or if you feel burnt out they all feel distant. That's because the net transports information so much better than emotion and sympathy. Some appreciating nod or slap on the back - this is all lost in communication. Hope you know what I mean. So I'm taking the chance to note here for all those working on Open Source software and especially KDE :

Thanks so much for all the work you put into this. So many people around me (including myself) are using it every day and have come to rely on it for their work and private use. I've already edited countless images with Krita so I sincerely hope you are aware that there are LOTS of people out there you have never heard off that really appreciate your work and that we all know very well that it's not granted someone puts so much work into sth. during their spare time. If you feel burnt out please take it seriously and take your time off. Nothing is more precious than one's health.

Thank you very much for the feedback. I understand very well that open source developers may feel exhausted and tired of working on such big projects at some point. Seems quite normal to me and I hope you didn't take my questions as some sort of criticizing. I know it can be quite hard indeed, especially when bad luck comes on top of it.
I cannot offer help except bug tracking, but I'm sure people will step in at some point to provide help. Good luck and thanks for what's already done.

I don't think people really understand how big a help this really is for the developers. When somebody creates a short, to the point and concise bug report, complete with how to reproduce a bug, it gives the developer a well defined task to work with. It is much, much faster to fix such a bug than to hear that "so-and-so feature doesn't work":

I'd also like to point out that there are several other ways that you can help even if you are not programmers. You can write documentation, you can create templates, you can create graphics, you can do UI design. You can also help spread the word or write magazine articles.

Nothing of this is as difficult as you might think. I know that some of the people in KDE development are totally awesome (and Boudewijn is one that comes to mind), but most people are pretty average. They dedicate some hours a week to KDE and still lots and lots of things get done. It's because of the numbers that we can make the software grow, not because we have a few dedicated souls who do all the work themselves.

This is a very good time to start developing for KOffice, even if you are unsure about your own abilities. We have several developers who started out without knowing much to start with, but who quickly got very productive. Join us in #koffice on IRC, or look at our website, http://www.koffice.org/. There is a special section for developers where a number of simpler tasks, so called Junior Jobs, are listed. I can guarantee that we are a friendly bunch, and that we will have suggestions on where you could start to wet your feet.