After more than three years of development, a total rewrite of KWord, KPresenter and Karbon. Major evolution in KSpread and Krita, to adjust to the new shapes-based framework, the KOffice team has released version 2.0.0 today, which is the first milestone for the KOffice 2 serie. You can read the announcement on koffice.org.





We are aware that this release is far to be perfect, and we still recommand the use of 1.6.3 over 2.0.0, but it open the way to further improvement, first with further bug fixes released in the 2.0.x branch, with three planned maintaince released, about one every month (2.0.x maintenance cycle) and with a 2.1 features release in October (2.1 Release plan).

The main goal of this release is to show the new technologies and user interraction. So we would like to encourage developers to have a look at what they can do as plugins, and to tell us about their experience. And to encourage users to test the new interface and to comments on it.

Missing an application to gather notes and ideas in KDE4, and willing to play with koffice's flake library, I have decided to start a new application called braindump which is a tool to dump the content of your brain (ideas, bookmarks, images...) to your computer.





For those who wonder why I did, apparently, start from scratch instead of helping with the port of a similar tool (like basket), the main two reasons is that I wanted to write a non-koffice based application to test the limit of the use of flake outside the koffice document based world, and the second reason is that I think that flake is the right technologie to do it:

• it gives for free a lot of shapes (texts, images, music, chart... other still in developement such as formula, marble... or in planning: video)
  
• if I miss a shape (such as a todo/progress), writting it is rather easy and makes it available for reuse
  
• it also gives quick access to ODF capabilities (for copy/paste, and importing/exporting information)
  
• and currently someone is adding change tracking (for history, and collaborative editing) to flake which should allow braindump to allow collaborative editing of sections.
  

The main application is 2300 lines of code, I expect that the size will double in order to connect all the missing bits of the UI. But then everything else will be in shared libraries.

Being in a playfull mood I also implemented a web shape for flake, making possible to insert web pages in koffice documents and in braindump:





The source code is hosted in the Braindump repository. You will need KOffice from trunk to be able to build. It's already somewhat usuable, and I am hopping that the first stable release can happen with KOffice 2.1 in October.

Among the cool new feature of Karbon 2.0, there is the Artistic Text Shape. It's a single line text (unlike it's sister, the text shape), which can be associated with a curve to do crazy things, or with a gradient:





Since it's not a highly discoverable feature of Karbon, I wrote a small tutorial to demonstrate the feature: Tutorial on Artistic Text Shape.

With Anne's tutorial on layout in KWord, this is our second tutorial for KOffice 2.0, but we need more of them, and we are looking for help in that area, since userbase is a wiki, go there, register, and start writting something, if you need advise, contact us on the forum.

Of all the application of KOffice 2.0, the one most ready is trully Karbon. It's also the one for which the progress since 1.6 is trully the most visible, and in 2.0, karbon is mostly a path editor (which is no doubt the central feature of a vector graphics application), and it's already working quiet well, definitively worth a try.

For a few monthes, I have already been using it, when I have to produce figures for my phd. And while I usually feel more confortable drawing with a pixel application (in other word Krita), I decided to make something more artistic with karbon, here is the result:

Since KDE 4.0, erm, I mean KOffice 2.0 is nearly its released, it's time to have a little bit of fun before going back to polishing and improving, and since the tag of RC1 last week, trunk is opened to features again. First completed features was to have a look at the now 4 years old autobrush, and to do some minor adjustement to its UI, and to add a little features.

Instead of width/height we now have diameter/ratio, this doesn't change much, but makes more sense with the addition of spikes, since the diameter now correspeond to the length of a spike, and the ratio to the thickness. And the fade is now expressed in percentage of the size, this avoid adjusting the fade when increasing the size of the brush.

Continuing with the spamming of nearly all communication channel that are available to me (no I am not going out in the street to shoot that information). With the soon to come release of KOffice 2.0, we have the need to start organizing the user community. We have started to fill some content to userbase, including experimenting with editing the handbooks on a wiki, starting with kword's manual (we need help for this, so if you are bored, and want to contribute something, well come and help with that effort). And today, the admin have open a KOffice sub-forum on KDE's forum !

So if you have a question about KWord, KSpread, KPresenter, Kexi, Kivio, Krita, Karbon, KChart and KFormula go ask to KOffice forum.

So if you know the answer to a question about KWord, KSpread, KPresenter, Kexi, Kivio, Krita, Karbon, KChart and KFormula go follow KOffice forum and hope someone will ask a question you can answer.

Today, I made a bunch of releases related to the OpenGTL project. Ranging from the main library, to some utilities and wrapper for Qt applications.

The main library comes with two version one for llvm 2.4 (OpenGTL 0.9.8) and one from llvm 2.5 (OpenGTL 0.9.9), the two main improvements are:

• a new memory management model, so far each time an object was created it was allocated in memory, and since most objects have a very short life time this was leading to excessive computational time, since putting all objects on the program stack was such a nightmare to manage correctly, I simply started to use a shadow stack with preallocated memory, this is less efficient than using the program stack, but gives massive speed improvement compared to allocating memory through the system


• a new kernel collection system, the previous system for collection of kernels wasn't practical to use and required compilation of all kernels at load time, which is very unefficient. The new one was written while doing at the same time integration in a real world application, aka Krita.

libQtGTL is a library that provides wrappers classes and configuration widgets for Kernel for use in Qt applications that want to use kernels, the screenshot below show an exemple of such use in Krita:




From now on, I also start to ship Shiva kernels in an external tarball, in shiva-collections, the goal is to update more often that tarball than I do update the library. It contains the examples that were available previously in OpenGTL tarball, and also some new effects, such as the calleidoscope:




All this is available at OpenGTL's download page.

Reading Sebas's blog (which unfortunately doesn't offer way to comments, which makes the only way to comment, a blog post...), sounds like KDE4.2.0 is not compatible with Qt4.5, which is hardly a surprise, but what is more annoying is that it sounds like the whole KDE4.2.x serie is going to stay incompatible with Qt4.5 (I might be wrong on that point, but Sebas mentioned KDE4.2, so it's unclear whether it is 4.2.0 or 4.2.x, in case I took the wrong assumptions, don't hesitate to comment on my mistake and ignore what's bellow).

The main thing is that all applications other than plasma or KDE4.2 might need to use 4.5, because they want to use a new feature, or an important bugs was fixed in 4.5. This is especially true in KOffice where one of the core component of an Office suite is developed inside Qt: the text engine. But this might be true for other project. Blocking the upgrade of Qt for the next six monthes seems very wrong to me. I hope plasma developers will reconsider their position, and provide a way for plasma 4.2 to work nicely with Qt4.5, so that progress in other projects isn't disturbed by this.