The combined KDE/Amarok booth and developer room at the annual Free and Open Source Developers' European Meeting (FOSDEM) in Brusssels was a great experience (as usual!). Many people showed up from the KDE and Amarok communities, and we had a hard time fitting all our cool hardware and people in the booth. Luckily, the talks drew quite a crowd, and the booth became less busy as the day progressed. Read on for an overview of FOSDEM 2008 from the KDE perspective.

FOSDEM started out with a large group of KDE and Amarok people working like crazy to get the booth set up. We had all kinds of weird (and more standard) hardware, from a KDE-branded SUN-based thin client and a small VIA box, to large and small monitors connected to laptops - and all of it running KDE, in some cases the bleeding edge of development (destined to become KDE 4.1). Meanwhile, the Amarok people showed off their latest work on Amarok, with an appearance of their Mascot, Mike, who came in from the woods to 'Rok with the crowd.

Amarok

After our group photo and a short welcome by Bart Coppens, Nikolaj Hald Nielsen gave a talk about Amarok 2.0 - the new way to "rediscover your music". Nikolaj also introduced a new friend, the Amarok Wolf Mike. Nikolaj then gave an outline of the history of Amarok, mentioning Free Software and the new trend which is going on besides the Free Software movement itself, the Free Culture movement - think Creative Commons or the rise of more open music sites such as Magnatune. Nikolaj is employed by Magnatune now, and he discussed some details of their contributions. It is great to see a company who really gets Free Culture and Free Software! In the future, thanks to the support from Magnatune, Amarok will support a variety of different music stores.

KOffice

In the next talk, Bart Coppens started to show us some cool and less cool things about KOffice 2. Starting with the bad, he told us how, due to the developers having less time to work on KOffice, the current state of several applications was disappointing. The developers therefore recently decided to restrict their release goals, focusing on the applications they can make stable for KOffice 2.0. Those applications will most likely be KPresenter, KChart, KSpread and Karbon. Yes, KWord and Krita both might not make it for the first KOffice 2.0 release! This is an very unfortunate state of events for the one of the most innovative office suites, and there has been talk of hiring someone to get KWord into a usable state for the release. Meanwhile, Krita is very complete in terms of architecture and features, but those features aren't reflected in the interface yet - and that may not change any time soon either.

Now, on to the good stuff: the target of the big refactoring of the KOffice codebase, getting a tighter, lighter and more integrated KOffice is finally starting to bear fruit. Two technologies were presented by Bart to illustrate his points. To explain the idea behind Flake, imagine rough terrain which is flattened out and made more consistent by snow flakes. With Flake as the backend technology for KOffice 2, the similarities between many different components are put into a common core. This makes the components much more lightweight, more flexible, and easier to write. Another technology is Pigment, the color management system which now allows all KOffice applications to have proper color management - something very interesting for people working with graphics professionally.

Bart showed elements from Karbon and KWord, and he talked a few minutes about KPresenter and the plans for that application. Apparently, Aaron Seigo has promised to work on it to ensure it works nicely with Xinerama and generally does what he needs it to do while giving talks all over the world. Unfortunately, earlier experiments with sound & video in KPresenter failed, mostly due to Phonon not being ready for Flake shape integration.

Nepomuk

After Bart, Sebastian Trueg entered the stage to talk about the Nepomuk project. Nepomuk is a research project with more than 20 organisations from across the European Union. Sebastian is mainly tasked with integrating the results of the research into KDE. The target of the Nepomuk project is to create a Social Semantic Desktop. Explaining, Sebastian gave the example of a file you once received from someone by mail and then saved somewhere. It can be difficult to find the file with current technologies, as that specific piece of information is lost when you save the file. Semantics are about relationships - and this file had a relation with the email. Nepomuk integration in KDE will allow you to find the file when looking for files related to the person you received the mail from. The Semantic Desktop will try to gather this kind of information automatically, or allow you to easily augment it so it can help you find your data or accomplish tasks easier.

Sebastian provided examples, explaining the benefits of these technologies and then continued to talk about the current state of Nepomuk in KDE. Currently, we have basic tagging, rating and commenting in Dolphin, and a basic search interface with a nice syntax. It allows you to search for rather specific things, but is not very easy to use yet. A final thing we will see soon is the ability to browse through the tags as if they were folders in Dolphin.

Similar functionality is planned for KDE-PIM, which Sebastian Kuegler now turns to. During a recent meeting, the KDE-PIM people decided they would love virtual folders (or live searches) within KMail. Such folders can show, for example, emails from a certain person or about certain subjects - and are updated live when new emails arrive or become tagged. Better search is generally something the PIM hackers want, and doing so by tightly integrating Nepomuk sounds like a smart move. All in all, the compelling vision behind Nepomuk left us impressed again.

Free software in Telecommunications focusing on Qtopia

Knut Yrvin works as community manager at Trolltech's office in Oslo. He started his talk by telling the crowd inside the developer room about the history of both Qt and KDE. Then, Knut started to explain the concepts behind Qtopia, Trolltech's extention framework which has its focus on developing applications for mobile and embedded systems. Qtopia allows developers to deploy quite advanced applications everywhere. The ease of porting desktop applications to Qtopia, especially with Qt 4.x is really amazing! We can only agree: as at the KDE booth Marijn Kruisselbrink (of KOffice fame) was showing KStars on a NEO1973 phone - and according to him, he only had to recompile it!

After the technical description of Qtopia, Knut went over the actual implementation of Qtopia running on hardware. Knut started showing off the Trolltech Greenphone (A developer tool which has been discontinued) and explained its advantages and disadvantages. Trolltech decided that they are actually not a hardware company and therefore shouldn't be really providing hardware but instead software that runs perfectly on it.

After the Greenphone went through the rooms and the usual "ooh" and "aaah" responses were expressed, Knut started talking about the next generation Open Source mobile appliances. The next phone running Qtopia is going to be the NEO1973, manufactured by a partner vendor with quite a few differences in comparison with the Greenphone. For example, the NEO is being developed very closely with the community. Another nice thing Knut mentioned was that Trolltech is also sponsoring the OpenEmbedded project.

KDE on Windows

Later, Holger Schröder gave a talk about KDE on Windows, starting with its history and progressing to the current status. Holger gave a demo to the crowd and showed off KDE applications running on Windows and interactively asked the public to ask him to show their favorite KDE program of choice. After the demo, he discussed the technical difficulties the team had to face when getting kdelibs ported to the (non-POSIX) Windows platform and explained the distribution system they had to set up for getting all KDE software distributed in a centralized way.

KDE Games

On Sunday, the KDE Devroom turned into a shared room with GNOME and other projects as it became the "Cross-Desktop" room. Unfortunately, we were unable to cover all talks going on, but we do have a short overview for you. After another warm welcome by Bart Coppens and Christophe Fergeau, Kurt Pfeifle and Simon Peter gave us an overview of the current status of KLIK on KDE and GNOME.

And during these talks, our booth received many interested visitors asking about KDE 4.x and the upcoming stuff, or looking at Amarok. Some were even working on code or hunting bugs - or blogging about the event. And, of course, discussing important issues like beer or things of less importance like code. We saw a few cool new things, like Marijn Kruisselbrink demonstrating Plasma running on Mac OS X and many different checkouts that each looked totally different... And don't forget about the neat Sun-provided thin client running Solaris and KDE. Or the fact we ran out of merchandise again ;-)

And of course, both days ended with lots of beer, fun and good food in Brussels! Until next year...

There is one problem: you cannot use the group encryption mechanism. In gpg.conf, you can define groups of keys. Now, when you have a mailing list with the same name, you ought to simply encrypt emails which you send to the mailing list address. Kmail now refuses to encrypt the email as there is no *single* key with the mailing list email address. Kmail does not honor the gpg groups.

KMail does not honor gpg groups, because the Author of GnuPG believes this should be solved on the MUA side. It is a too less known funcationality that you can select several keys in KMail. I am using Kontact and create a contact with my mailinglist as email address and then add all the encryption keys in there. This basically is the "group" feature, but it is implemented in a higher layer just has Werner Koch recommends.

I have helped someone testing the (then new) GPG support in Thunderbird using KMail - it has had excellent KGPG support for years... So unless you are talking about KDE 4 (but KDE PIM hasn't released for 4.0 yet) I wouldn't know what you want.

(At most one of which are paid - contrast with OO.o's sprawling and horrific codebase, which has about *50 *full-time* programmers working on it).

A really sad mis-allocation of funds if you ask me: if I was rich, I'd definitely be putting money into KOffice rather than OO.o. It's amazing how far the KOffice team have come on a non-existent budget, and a real testament to how good the devs and underlying technologies are.

50? There are about 10 full-time folks in o.org from SUN and who knows how many in Novell (not counting marketing and lawyers ;) ). You can find not that many commiters with 2000+ commits (http://www.ohloh.net/projects/29/contributors). Most of the code still comes from closed source development at StarDivision.

Thanks for the offer and we all are waiting for you when you got rich :)

I doubt they count the translation teams either when talking about numbers of developers. About 120 developers for OpenOffice sounds about right to me -- it's what I'd expect for a codebase of that size.

But much of the code has been provided by StarDivision. The question is about actual # of devs, not history. While oo.org 2.0 alpha/beta stage, the team has been complaining about shortage of manpower.

The news about KOffice are a bit sad, though not exactly new : KOffice has always lacked developpers, it seems.
It's probably too late for KOffice 2.0, but maybe there could a good focus on KOffice for the Summer of Code to attract young dev to this office suite?
I really wish it to grow, as the latest Alpha version I've tested was very promising.
By the way, I've read the blog on planetkde about MS binary format and why they're so complicated. I promise I'll never ask again for better MS filters in KOffice. :-)
Would be nice to have a command line tool using OOo filters to immediately convert to ODF without having to load and save in OOo though...

I wonder if one of the problem of KOffice isn't the rewrites, I don't follow its development closely but each time, there's talk about 'ground rewrites'.

If memory serves, KWord has been rewritten from scratch, which explain that it may not be ready soon..

I agree with your point about using OOo as a filter: no need to waste development hour on this point, it may be a bit big in disk space but stripping everything not needed from OOo could reduce this point.

so kword might not make the first offical release. Hmmmm. That's not exactly a smart idea, especially when a word processor is the main reason people have for office software.

Personally I tried KOffice 2, what ever alpha or beta it is up to now, and it really was a waste of my time. It's like comparing an apple (microsoft office) to a peach (open office novell edition) to a sour old dried up lemon (koffice) I really do not think any windows users will be using that software, and the vast majority of linux users wont either, it's so lacking, and well, ugly. The GUI looks dated a decade compared to how office suits look now.

What do you expect from ALPHA quality software? It is lacking feautures and the GUI indeed needs some attention, but they are working on that. And if you've got good ideas... just let them know by bug reports.

Although I agree that a word processor is the key element of an office suite it might be usefull to have the base libraries and base programs (without kword then) out, just to make other developers aware of the infrastructure, IIRC Koffice 2 is using new baselibs and infrastructure, just like KDE 4 is using a new base.

I do like though that kpresenter has gotten a bit of love, the 1.6 version wasn't that great at all.

I really don't get how you got to that impression. Didn't you by any chance try OpenOffice and mistake it for KOffice? I mean, that one looks like MS Office 96, sure. But KOffice looks rather different, and has a few pretty cool things. I just gave the latest SVN a try. It's not ready for use, sure, but some stuff is incredibly cool - esp vector graphics stuff in there. I'm really looking forward to a more stable KOffice.

FIrst i would like to show my appreciation to the KOffice devs for the wonderful work that they are doing, for their time sacrificed and their talents. They are few and therefore have come a long way but it's just not enough compared with openOffice like you pointed out.
I am just wondering if it wouldn't be a smart idea and more productive to join force with the openOffice guys. I mean, openOffice is improving so fast that I think it will be impossible for KOffice to catch up with it's present resources.
I am not a coder so forgive me if I am wrong but wouldn't it be easier to develop a Qt interface for openOffice and have it better integrated in KDE than to programme a whole office suite?
I personally think that there is too much duplication of efforts and wasting of resources in the opensource world.

OO.o's codebase is so huge and wretched that I honestly can't imagine anyone volunteering to work on it on their own time, and there's no guarantee at all that Sun would grant commit-rights to outsiders (OO.o is developed very much in a Cathedral-style). Frankly, I consider working on KOffice a vastly more appealing prospect, *and* in terms of technology it is by far the "best bet" if you want to make rapid progress. The lack of money spent on it is the *only* thing keeping it from absolutely crushing OO.o, in my opinion.

No, it would be much harder to rewrite OpenOffice with Qt. OpenOffice.org codebase is so complex that it will really take away good developing time only to port it to Qt. In contrast, KOffice 2.0 is being rewritten and easier for developers to code (cleaner code base as well).

I believe currently KOffice has a very good technology (flake, pigment, etc) that will create a superior office suite in the future (given enough developers to pursue the dream). For example, using Flake technology you can embed any shape (chart, spreadsheet, vector graphics) in any KOffice application. This technology enables good component reuse and also better interaction among application.

1.) I don't think OOo is improving fast. They have to invest huge efforts to clean up the code and architecture (there a lot of work left for several years). And to be honest, I didn't see a lot of real improvements from 2.1 to 2.3 (and even the upcoming 2.4).

2.) Imagine the few KOffice developers helping the huge OOo team. That wouldn't make a lot of difference for OOo. Especially as the KOffice's developers expertise is in slihgtly differnent topics.

3.) KOffice has a extremely nice basis. Just a little bit more development power, and it would show up as a nicely polished Office package.

4.) It's very nice to have several different office packages. They can serve different purposes and thus have differnet focus/strengthes/GUI (does OOo have something like Krita, KPlato or Kivio?). And having different bases helps to detect defects (like ODF support in the past in OOo an KOffice). Imagine a piece of software that has no competition - progress stalls!

To sum it up: If KOffice would "join" OOo, it would mean very very little gain, but a big loss.

I post this with the demobrowser that comes with Qt4.4, and while typing in this textarea is slow, and takes around 30% CPU, I have to say painting is soooo fast now, the browser feels more lightweight than whatever I have seen in 8 years of linux.

Also, the speed of painting is very fast visibly when hovering over the open menu in the browser.

I like it, it looks that Qt is finally faster than everything else in painting :-)

I put some buttons and stickers on cafepress long ago. some of them are using the old kde3 logo, others are using the generic two-colour one.
given the amount of effort it took to tweak the images into looking decent on cafepress, I don't think I'll bother updating it with the kde4 images.

disclaimer: I did put a markup of a few cents on each item (I didn't see any rules disallowing this where I got the logos). I'm planning to use the money to buy more of the mini-buttons - there's almost enough for a pack of ten now :) http://www.cafepress.com/chanika

As far as I know money isn't a problem. Thomas Zander(?) wrote on the mailing list that he secured a sufficient amount of money to pay a full-time developer for several months (I think it was 2-3). The difficult part is finding someone who is very familiar with the KOffice codebase and willing to work on it in the time span before the 4.1 release (after all, most people probably already have a day job are are otherwise impeded by other commitments).