As you probably know, I work on KOffice. Have been doing that since before the first release and I did most of the (flake)libs and KWord work in the sprint to the upcoming Koffice2.0 release.

A big reason for working on KOffice is that its fun! Another, at least equally big reason is that I believe KOffice is the best open source office suite for the long term. And so follows the question; What makes a successful open source project?.

If we look at what others have said on the subject we come to the conclusion that the things that count most are these 3 points;

• Good idea
• Running code
• A community

Today I want to highlight the "community" part, as various others have been doing on blogs in the last couple of days. Without community there is no future in the project, since new contributions come from the community members. So without community the new contributions (code/docs/bugreports) dry up. Its that simple. Sustaining a community next to creating great code is a balancing act.

What I love about FLOSsoftware is that you can create a great piece of work and others will try to build on top of it, including improving your code. The most obvious way of doing that is reporting bugs, but a lot of people are actually providing feedback on your work as you do it. Which creates a really great atmosphere of working where you create stuff that you could not have created were you working on your own in a closed source setting. I always appreciate people giving constructive feedback on my work.

As a stark contrast I have been getting more bothered by the rise of people that seem to feel that just writing code is good enough. If someone feels the need to provide constructive feedback, or just even ask why a certain solution was chosen I have been amazed by the responses such community members write. It tends to be along the lines of "This is my code, let me do what I like in peace!"

You might have seen this yourself, but examples always help (removed all names for obvious reason).

Edit; it turned out that using two real life examples was not a good idea, I removed them to refocus this article on the real content edit.

If you have the attitude that you don't question other people you will naturally see the very healthy and normal open source attitude of peer review as personal attacks. For the simple reason that the only reason you would ever discuss items is if you disagree with them. So others must obviously disagree with you if they ask you about your work.

These two ways of thinking (the collaborative and the "I do my part" ways) are obviously in conflict. Whenever differently minded community members meet bad emotions and disruptive events happen. I've been in a couple of those in the last month and I can tell you they are very much draining me of my creativity.
Worse, I note that this behavior is spreading; people that are behaving in the way that what they do is obviously the right thing and feedback is not going to lead to an open discussion make other people more closed minded as well. And we loose a bit of our community every time such a conflict happens.

What do you think we can do to improve this situation?

You can find more blogs from here at this space; labs.trolltech.com

KWord in trunk (we recently got an alpha2 out) is not the same piece of software as it was in KOffice 1.x, its gotten such a makeover both internally as externally that its largely unrecognizable (in a good way). This also means that old known functionality may have problems due to it being new code.

When I woke up this morning I found this on #koffice

01:24 * astan zz.
01:24 <BCoppens> night
01:47 <astan> hm. is it possible to insert text frames in kword yet?
01:58 <astan> ok, i've just made my first commercial document using kword2 a receipt for this bicycle i'm buying for my book café.
01:58 * astan zz for real.

I guess that after compiling KOffice from svn and taking that extra half hour to do real work on it, KWord passed some sort of test

Some time ago I blogged about how KWord can now run around the outline of any shape you place in its text flow. One thing I have had on my TODO ever since was allowing a user to create a custom run-around outline that is separate from the outline of the actual shape we run around.

Yesterday morning I woke up and realized that actually its not that hard to do, and even while it was a feature for post-2.0 I sat down and did it anyway. Just 2 hours later I had a working prototype and this morning I dotted the I's and committed the stuff.

It works like this;

Every now and then I start kbugbuster and browse the bugs database for KWord. I can then happily close a dozen or so bugs without having to code anything. The reason for this is that basically KWord has undergone a rewrite for 2.0; when we switched to Qt4 and the basic text engine was replaced with Qt4s-scribe and the frames were replaced with Flake it turned out it wasn't useful to refactor the code but more to merge in old code when and where possible.

At the same time I redesigned a lot of core components. Can't let an opportunity like that pass. I had the experience on how it would have to look and then its just a matter of writing the code.

Now, if you start the new alpha release of KOffice and see a KWord that still misses loading and saving, instead I see a KWord that got its guts ripped out and replaced with shiny new components. Really 2.0 like.
And I got some numbers to prove it! If I check the amount of bugs closed in the 16 months (since the redesign was started and work on 1.6 stopped) I note that 312 reports were closed. So without actually trying to fix bugs the redesigns just 'magically' closed over 300 bug reports and wishes.

I only closed bugs that are actually properly working now; with working GUI items and all. Which means that redesigns which are started, but are not yet fully finished still give me room for more closing of bugs.

So, when I can close 2084 days old bugs, I think the work I did on Kword 2 was due

If you ever did anything with multithreading you'd know mutexes. They are basically a building block to do any multithreading work in.

In java they are better known as 'synchronized blocks'. Your basic hot zone can be protected by a combination of myMutex.lock();  /* do stuff here*/  myMutex.unlock();
Which is equivalent to the Java manner of synchronized(myMutex) { /* do stuff here */ }

My biggest problem with the mutex method is that if I add a return before the unlock part, I've got a problem. The mutex will never be unlocked. So you will get weird errors that just when that corner case happens which will do such an early return, things will lock up.

So I tend to write the following:

You may have thought about using the excellent Threadweaver from kdelibs to speed up your application a bit, but got scared of the horror stories of multithreading in C++.

One common case where things may go wrong in C++ is deleting of objects. For example when you have an object like a "User". Your painting routines quite likely access that user object, for example to show that QImage of the users face.

One of the things we wanted to do in KOffice is to use Krita when printing images from KWord. The reason for this are a couple, but the most important being that we want to have just one way to do printing of images and not waste time maintaining a more than one.
Naturally the option to let Krita convert the images to CMYK while printing (as soon as QPrinter supports that) sounds like a nice to have as well.

It turned out to be a bit harder than I first thought. The reason for that is due to the way that Flake works is that is separates processing and painting. The painting is reused for printing and painting always has to be as fast as possible; so no expensive calculations there. This keeps the interface snappy and user friendly. And I know you want that.

So, the problem is thus that painting is designed to paint the stuff we can paint right now; even if thats not the full content. The top couple of paragraphs of text, for example. And when the rest of the paragraphs have been properly layouted, then we'll just paint again. This concept works great on screen, but breaks down when printing. We don't want partial text on paper, we should wait until the whole text is positioned.

This effectively means we need someone to monitor the progress of a flake-shape and when its done with all the processing we can start painting. And this quickly means we need to do multithreading.

For that reason I added a KoShape::waitUntilReady() virtual method that a flake-plugin should implement if it has the problem that it can paint partial data. The idea there is that I call that method while trying to paint, and the method doesn't return until the shape is fully ready. After which I paint it to a printer. I implemented this for both the text shape and the krita-flake shape.

KWord now starts printing in a new thread and checks the quality of the images, loading the Krita shape plugin when it needs to. It will then drop back to the main-thread to actually do the painting of the shape (so shape-authors don't have to worry about multi-threading and locking). And it repeats this for each page.

It prints just great (and correct too!); while keeping the user interface snappy and responsive.

By now I wrote a nice collection of useful tools for multi-threading for KOffice. There is a KoAction which is the simplest interface you can use to make code run in different threads. There is a KoProgressUpdater which is a helper class to update progress of a task on a QProgressBar, from any number of threads. Naturally the new KoPrintingDialog this post was about. And we now have a KoShape::deleteLater() which is a thread-safe deletion of the shape. Required so we don't delete a shape that's just being painted in another thread, which would cause a crash.

Flake now doesn't just rock for easy painting and editing, it also is great for multithreaded applications and professional printing.

Some weeks ago KOffice alpha1 got tagged; but some balls were dropped and it never was uploaded to the ftp site. The good news is that even more new cool stuff is visible in the KOffice Alpha2 which will probably come out end of August.

One of the cool things in our Flake library are the ease with which you can make vector shapes. As Jan demonstrated by basically having a string of coordinates as a new template and coming up with a shape we call the Gearhead Jans blog. This addition is done in a C++ plugin right now; but we plan to add support so adding this kind of template can be as easy as pointing to a text file in the shape selector.

I rearranged my todo list a bit and did some required features as well as some features that were really scheduled for 2.1. But I just wanted to do them now. Sometimes you have to shake your fist at planning! Even if you are the only one actually overseeing the plan.

I added a feature that I think is pretty cool to have; its called text greeking. Basically when you paint text and the text ends up being really small (like a couple of pixels per character) you can't really read the text anyway. In this case I just paint a general block in the place of the text which naturally is quite a bit faster. This means that if you zoom out a lot that all those pages you see are still rendered quite fast.
I intend to use this concept in a page-selector; which can then paint the actual content in real time as its changed in the document without noticeable slowdown.

I have been seeing quite some good commits in KWord ODF loading from both Dipesh and Pierre Ducroquet. Going through the ODF testsuite I notice more and more testcases that KWord is passing. Chakka!

Another redesign I made in KWord has to do with images. We now lazily load images from disk; so you can have a document with tens of thousands of high quality images loading quite fast and taking not a lot of memory. And only when the images is shown the first time will it be loaded from disk for a preview. You can also set an image to be previewed in a low resolution to speed this up and conserve memory use. I'll be sure to make KWord print the high-res one when printing, naturally

Redesigns are useful when you have to write new code anyway; as I noted when I was going through our vast database of bugs for KWord I managed to close about 20 long open bugs that basically disappeared due to rewrites and redesigns at the lower level.

An example of such a thing is a new approach I took to footnotes. For those that don't know the term; its a often used concept of adding a marker in text, like a '1' and adding some text at the bottom of the page giving extra info. KWord used to implement the concept using frames, which means that if you have a footnote in a multi-column document you still have a full-page-width footnote at the bottom of your page. So I took a different approach and I embedded footnotes in the text-flake. Which means that the footnote is rendered at the bottom of the column in KWord. If you use the text-flake in an application like Krita or karbon you will now also be able to see the footnote. Which people will surely be able to see usages for. Creative people always do

Last item of today; Casper has started to do a rewrite of the ruler; which now looks like this:

Its still missing guide-lines and some other stuff it had in 1.x, but I believe he is working on that. Let us know what you think!

The last couple of days [1] I've been working on bi-directional text in KWord. KOffice as a whole is aimed to be used worldwide, in all sorts of environments and it has to be usable for all sorts of scripts and languages. I'm proud to tell you that the todo list on getting that done is starting to be really really small.

Here is a point wise list of things that we now do properly.

• KWord and KOffice supports Unicode 5.0. This means in rendering the fonts and loading/saving as well as being able to type all known scripts.
• BiDi text rendering, and cursor navigation works as expected.
• KOffice text now has smart auto detecting for directionality of text while the user it typing it. And it will change the direction properly.
• Inheriting of text direction is made possible; you can set the direction on a document so a latin paragraph in hebrew text is not automatically changed since that would look out of place.
• The alignment buttons are properly positioned and function as expected for all text, and also when the application is shown right-aligned (--reverse for us europeans). This was a long standing bug that I fixed.
• Smart showing of directionality button. You can manually alter the direction of a paragraph by clicking a button in the docker. This button will only be shown if the document has mixed directionality already.
• List items and brackets are properly reversed on right-to-left layout. A user having a number and a list-item suffix of ")" will see that being a "foo (3" on a right-to-left paragraph.

Last year I had some Hebrew lessons from a friendly Israeli, the rest of this stuff I got from books. So please do download KWord alpha2 in a couple of weeks and tell me if I missed anything!

1) you may have noticed these commits in svn some time ago since I wrote this blog a week or two back already while kdedevelopers.org was down.