KDE will be moving to git, Qt has moved to git, recently also CMake moved to git.

So, it's time to start using git.

...until now it really looks so complicated, compared to cvs/svn.
In cvs/svn it was easy: local working copy, remote central repository, just one step away.
With git this is about three steps away: local working copy, stash, local repository, remote repository. You always have to be aware of where things are.

Ok, one has to get used to that "git add" is something different from "svn add", and "git commit" is different from "svn commit".

1) Create a folder somewhere eg ~/Desktop/My Favourite Apps
2) Drag and drop the folder onto a panel
3) Choose "Folder View" from the popup that appears
4) Drag apps from the menu, documents from Dolphin and other stuff onto the new panel icon
5) Click it and enjoy your new menu!

Rendering slides is a complicated business. Slides can contain tons of different features just like webpages can. People expect that presentations look the same in different programs. Perhaps not pixel-perfect but very similar nevertheless.

OpenOffice and KOffice (and the Maemo/Meego Office Viewer) both have ODF as their main file format. ODF is an open standard and this means exchanging data between these programs should be simple and lossless. To help the developers of these programs find differences in rendering of slides, I have written a program that loads a presentation and shows it as rendered by KOffice and OpenOffice.

As an added bonus, it also shows how these programs render PowerPoint files. PowerPoint files are converted to ODP first and then loaded into each of the two rendering engines. That gives four types of output:

• Converted by OpenOffice to ODP and rendered by OpenOffice
• Converted by KOffice to ODP and rendered by KOffice
• Converted by KOffice to ODP and rendered by OpenOffice
• Converted by OpenOffice to ODP and rendered by KOffice

You can see an example view in the screenshot and screencast below.

The code has been announced on the koffice mailing list.

Ogg Theora screencast of SlideCompare
Flash screencast of SlideCompare

I haven't blogged about my development activities for some time now...
So here come some news.

We released KDE SC 4.4.
There were no really big new features in this release buildsystem-wise. Nevertheless it was enough work. PolicyKit support has been added, which was quite some work, and all the new Strigi/Soprano/Nepomuk/Raptor/... stuff, which is still quite confusing for me, and which broke our buildsystem during the 4.4 cycle for a few weeks. But we got that sorted out too

I have fixed Exmap, my still favourite tool to measure system memory usage, to compile with latest kernels, and also to work on x86_64 (the latter was a bit of guess-work, but I think I got it right). KSysGuard seems to be getting close, and with Exmap unmaintained by its author I don't feel like doing this forever, but for now, it's still possible to get exmap from my home:llunak:kernel repository. And as I don't feel like trying to do cross-distro kernel packages in the buildservice, those not using openSUSE are left with either trying to package it for their other distro, or pick out the patches from the .src.rpm .

While I was at it, I had just a little look at memory usage. Since I had done quite some comparisons of KDE3's memory usage with other desktops in the past, the first thing that came to my mind was doing that quickly again. As these days LXDE appears to be the new lightweight kid on the block, I tried that one, and also Xfce. Finally there's TWM, basically just to show the memory usage without any desktop. All of them are default desktops on openSUSE 11.2 for a new user with a file browser and terminal open, the only exceptions being adding a mixer to the default Xfce setup for a reason that will be obvious later and not using the nvidia driver. LXDE is from the X11:lxde repo, KDE version is 4.3.5 that'll soon end up in an online update. So, here it is (for those who don't want to find out what all those values mean, the most important number here is the 'Effective Resident TOTALS').

Of course, this is not really comparable to my old memory usage test, for a number of reasons, such as this being x86_64 machine, the setup being different, and so on.

It's interesting to note that LXDE actually loses to Xfce. That 'python' there is in fact GMixer. That really shows that you don't get lightweight things unless you check the setup yourself. And it probably also shows that you can get lightweight things only if also your expectations are lightweight.

It also shows that KDE4's memory usage is not as bad some some might think, although it would be nice if somebody would be bored enough to analyse it in more detail. There seem to be enough people bored enough to just complain about KDE4 performance but not do anything else, and this is actually pretty simple. Or do you need an Akademy talk for that or what?