KWord will get a new textengine in version 2.0, it will be based on Qt4s scribe engine. And I've been working on this for the last week. Scribe gives me the ability to implement just the actual sizing and positioning of lines. Which means a minimum of code needed to do cool things. I like that.

Maybe people remember I posted screenshots with text layouting already being done. Thats true, its just that that code was simple (and incorrect) proof-of-concept code and I removed it as it has served its purpose. Starting from scratch; take 2.

If you develop like me, you will most likely have a lot of 'change source' 'compile' 'test' roundtrips. Each roundtrip will need a 'make install' to actually be able to see your changes. So, after we optimized linking by dumping libtool, installing is the place to look.

Red Hat is looking for a diverse group of people to take this survey entitled "what do you think of us?"

What about your help?

First of all; I'd like to say that CMake is a nice technology; its cross platform, and saves us from the braindead auto-tools, but most importantly it basically gets the job done.

There are two basic settings for a mailinglist with regards to where replies go to. The one KDE uses is that replying goes to the list. An older standard is that replying goes to the person that send the mail. This distinction is very annoying to make each time you switch mailboxes. KMail already makes it easier for you by having a feature that a mailinglist can be associated with a folder. But that one is not very foolproof, and I like playing a fool when it comes to software :)

Most graphics applications have a toolbox in one way or another. A floating window that contains a lot of tool buttons for, well, the tools in that application.
Karbon was the first in KOffice to have one, Krita followed last year. KWord practically speaking already had one, but I personally saw the toolbar with 5 icons to insert new things never as such. Even while I was the one that made it stick to the left by default, its funny how that works.
In KOffice 2.0 we plan to make the toolbox something that is used in all KOffice applications.

In KWord the main library is called kwordprivate. So doing a recompile after changing something inside of kword cmake has this nice gem:

make kwordprivate/fast install/fast

Works nice in general, except for this fantastic dependency problem:

The 1.5 series of KOffice has been a good one for the suite; with several new applications and a much improved stablity for its main applications one thing became clear, we got new people that started working on KOffice. You have to admit; for such a small team of people its a pretty big suite to maintain. After all we truthfully state we have the suite with the most components on our website!.

In KOffice the flake library for shapes is taking a much clearer form now KWord is actually really using them. Details like shape-configuration widgets have been flashed out. A tricky think considering its plugins based.
In the last weeks I've also been working on getting a text-shape operable. Its pretty cool to have a couple of text-frames as you know them from KWord, but you can edit the text even while its rotated or skewed. Much more work has to be done to enable real DTP like features, though.

Open document format is that new fileformat for Office suites, ISO certified and genuinely an open standard.
Its been busy in ODF land, since early may the ISO certification came through we have seen the market accept this standard in an amazing speed. Governments are not well known for moving fast, and yet we have this long list of successes.