We can't have too many plasma clocks in KDE4, and I'm pleased to say that the Ruby analog clock is now working pretty well. I've been using it to time brewing a pot of tea this morning, and there is certainly a more delicate taste to Earl Grey timed with a Ruby clock as opposed the the slightly coarser and more acidic flavour that using a C++ based clock applet as a timer, can give to your cuppa.

KDE 4.0.3 is out and openSUSE packages are available at the usual place as is a new "KDE Four Live" CD.

Just want to note that these packages are less pure KDE 4.0.3 with every day we near the openSUSE 11.0 feature freeze. Last week-end I started a "Plasma 4.0 openSUSE" work branch in KDE SVN to combine our local patches, upstream backports and own features. The goal is to ship a KDE4 desktop which has not less functionality than a GNOME desktop - means eg adding / removing of panels, a simple way of being able to move plasmoids on panels and the theme selector are in there. You can find this stuff already merged into our KDE 4.0.3 packages. Some outstanding tasks are using the Kickoff look of trunk and dealing with the desktop icon issue. Currently there are of course also some glitches to chase down during the bug fixing months until the final release.

If everything turns out fine in the remaining time until the feature freeze we will have a KDE4 desktop without any by default running KDE3 application. That includes update notification applet, kpowersave, front-end for NetworkManager 0.7 and if you like Kerry. And as you are maybe already aware: YaST (installation, system configuration, live installer), package selector and X configuration tool are already using a Qt4-frontend respectively are ported to Qt4.

FOSSCamp is happening in Prague next month. This is a general free software get together with sessions on whatever participants want (it happens just before the Ubuntu Summit but is otherwise unrelated). A good number of KDE people are expected but more welcome. Jorge explains all.

The Hippy Horse edition yesterday caused much jolity and occational bewilderment. Wasnae me.

As every year, one can see all kinds of articles related to today's date everywhere, ranging from quite amusing ones (it's a pity I knew what day it was when visiting dot.kde.org) to really old boring ones without anything interesting in them. I guess many people are running out of ideas or something. Rather that doings things like that, I think such people should simply stay serious. Like myself, I'm a pretty boring person usually, so I won't join the crowd, but I'll rather try to fight back by trying to be serious.

People who have tried KWin's compositing have different views on how well it performs. I have seen comments starting from "it's so unusably slow, and Compiz runs fine here" to "it runs so great, unlike Compiz". I guess it really depends on one's luck and the gfx card, X version and drivers in use. Here KWin runs comparably to Compiz, and that's with several different setups (and gfx cards, and drivers). Quite hard to do something for people where it's bad for some reason, really. My crystal ball refuses to work whenever I try to use it on compositing problems, and here compositing works for me (TM).

Actually, that's only with either the development version of KWin or the to-be-4.0.3 version. Some days back I found and fixed some inefficiencies in KWin that were way too often causing pixmap-to-texture conversions, slowing it down, or other problems (see the 4.0.3 changelog when it's out). These fixes also allowed me to again enable KWIN_NVIDIA_HACK trick (i.e. __GL_YIELD=NOTHING, see Nvidia's README), making KWin actually seem to perform even better there.

Update: Saying that one is not going to fool anybody does not necessarily mean this saying is just not part of the fooling. It was for a reason why the first paragraph and the very last sentence were somewhat ambiguous. It seemed funny at that point for some reason. But I guess I took it a bit too far with pretending all of this is serious, most people probably don't have the knowledge to know that, since compositing is an additional pass, it cannot make things faster in general. Although, and that should be the lesson, things rarely in practice magically become five times faster. Glxgears is not going to actually get more work done just because you postprocess it. So yes, sorry, the part below and the video are a fake.

However, the parts above are not, they are true. I really have recently done some optimizations in KWin and it runs here comparably to Compiz (on some setups slightly faster, one some somewhat slower, but it's not a significant difference). And, with the Nvidia trick, the perceived performance for some users in some cases actually may seem to be five times better. And, this time unfortunately, the parts about it mostly working for me and it being difficult to do something about problems other have that I don't see are true as well.

End of update. The video that follows is a fake.

And, speaking of tricks, as a result of seeing and fixing those problem, in my local version I've tried some more performance improvements based on that. By applying even more optimizations to KWin's handling of pixmaps and OpenGL textures, KWin now can avoid even more unnecessary redraws or pixmap-to-texture conversions, leading to a rather noticeable difference. In fact, since it's an accelerated desktop, glxgears running with KWin's compositing now even runs faster than without compositing (I know glxgears is not that great a benchmark, but it's good enough for some uses). You can see it for yourself here, or if you've found out that Flash sucks, then you can download the video here (you'll probably need to set the video to fullscreen to see the FPS numbers in Konsole). As you can see, the gfx card is not very fast, and the recording of the whole screen for the video makes it appear even worse (throughout the whole video, unfortunately, that's why some parts are quite choppy).

That's all, the usual old boring stuff .

Google have extended the Summer of Code 2008 student application deadline until April 7 so if you were busy last week or concerned your application wasn't good enough, now's your chance to get it in.

And I took the opportunity this morning to add an idea that we could really use on the Free desktop - a way to sync wallet secrets between different computers, and maybe between KDE and other secure stores like GNOME keyring and the Mozilla password manager. If you think you're hard enough, please apply. It's a non-GUI job, and involves getting your hands dirty with various APIs and solving some tricky problems - just the kind of skills needed to make yourself useful as a professional Linux hacker.

Today's Kubuntu Hug Day looks at bugs in Launchpad with comments regarding the KDE bug tracker. Join #kubuntu-devel and #ubuntu-bugs to help out.

In my last blog, the screenshot showed a broken image.

Thanks to some very fast work by Tobias König (tokoe), it now works. That picture of Konqi was uploaded to the server using Outlook, and downloaded using OpenChange and Akonadi, before being rendered.

[Image:3361]
(again, click to expand).

Thanks again to tokoe.

Spent some time today getting the OpenChange resource for Akonadi up and running again. I haven't really done anything to improve it from where it was a few months ago (OK, September 2007, when I was on holidays), but it lives again.

Those few months have involved a lot of changes on both the OpenChange side and on the Akonadi side of this resource. However we can still read mail (kind-of) and show contacts (kind-of).

Screenshots, using the akonadiconsole tool:
[Image:3358], [Image:3359]
(click to see full size).