Alas (and alack), I have reverted to using KDE 3.5.8. I wasn't going to, but yesterday then KDE 4.0.0 refused to load for some unknown reason, and I got thinking: Was it worth trying to fix it? Unfortunately, I could only think of four reasons to use KDE 4.0.0, and they weren't very convincing:

Reasons to use KDE 3.5.8

• It's a stable, well tested system which has had most of the rough edges whittled away over time - and most of the time, it just works. (This reason could be expanded into many bullet points - one for each thing in KDE 3.5.8 which works which is broken in KDE 4.0.0, but I'll leave it rolled up into a single bullet point to save this looking more like a rant than it probably already does - and leave the bug reports in bugs.kde.org).
  
• I don't have to use AIGLX (the non-compositing version of KDE 4.0.0's KWin isn't very useable), and so everything is much faster, Google Earth works and I can watch videos. (In KDE 4.0.0 kaffeine and codeine just show an empty black box)
• I can set up the panels just how I like them. (One medium sized panel at the bottom for the K-menu, the task list (or whatever it is called), a clock and the lock/logout buttons, and a small one at the top for a 'quick launch' bar, the pager and the system tray.)
• I think the style I use in KDE 3.5.8 is sharper than Oxygen currently is, which looks a bit blurry somehow - I'm not exactly sure why though. But it makes it nicer to use.

Reasons to use KDE 4.0.0

• Plasma on the desktop can be pretty (although it tends to crash a lot).
• KWin with compositing looks cool.
• Tabs in the Oxygen style look kind of nice.
• I can find bugs and report them so that KDE 4.0.1/KDE 4.1 can be better.

I am well aware that KDE 4.0.0 is actually a beta release which has been release as a .0 release to try to get more people to use it so that more bugs can be reported and fixed, so I can't complain too much (although I would strongly argue for not releasing betas without the beta moniker, but that's another rant). I'll still boot into KDE 4.0.0 from time to time (that is, if openSUSE's packages fix themselves soon!) and look forward to KDE 4.0.1.

Never try to catch a train last minute...

Yesterday I tried to catch a train last minute. While running towards it I fell down. I got up again and managed to get it.

While sitting in the train I realized that my arm hurts and at my destination I went into a hospital. The X-rays revealed that my ellbow was broken ;-) Nohting serious --- it'll hopefully heal within two weeks...

So my advice clearly is: Never try to catch a train last minute --- let it pass!

And the moral is: The next train would have departed in only 30 minutes...

Damn!


P.S. In the next two weeks you'll only get short messages from me since I can only type with one hand :-(

I've now had KDE 4.0 installed for just over a week, and I'm getting used to its quirks. I'm very impressed with KWin - it hasn't crashed on me once. At least, not since I got the right combination of options (for me, the intel graphics driver instead of the i810 one, and OpenGL instead of XRender). And it's a darn sight nicer than compiz. I always got frustrated by compiz because it didn't understand KDE properly, and I couldn't use Alt+RMB to resize and things like that. And it would crash. KWin just works, although rather slowly.

Generally, KDE 4.0 seems a fair bit slower than KDE 3.5, but I think that might be down to the compositing stuff. Also, there are quite a few little niggly bugs which I hope will be fixed by 4.0.1. I've reported a few bugs, but I'm still trying to work out reliable ways of reproducing some of them before I report them.

I said in my last post that I was inspired to start coding for KDE 4.0. Well, as usual, my inspiration has quickly waned as I moved into a new house and have more useful things to do at the moment, such as painting. So don't expect code from me any time soon.

Usually I write blog posts announcing what I have done, but this time it is useless. So I’m going to blog about what I’m going to do. After latest Strigi irc meeting, I came out with this task:

KDE integration: Flavio will coordinate the definition of interfaces over which KDE will handle searching and metadata. He can ask Aaron, Evgeny and Jos for help with the interface design. The interface will cover:

• Querying via Xesam

• Configuration of the Strigi daemon

• Indexing and deindexing of data by passing it to the daemon (allowing for indexing for more than just files)

• Controlling the daemon (starting, stopping, pausing)

Once this interface will be ready, it will be easy to integrate Strigi functionalities inside KDE programs. This mean (just reporting the most relevant cases) that it will be possible to create a Strigi krunner, have metadata extraction inside Dolphin and Konqueror, interact with Akonadi…

Talking about Xesam, right in these days I got a mail from Fabrice Colin, author of Pinot. Recently Fabrice made some improvements on Pinot’s XesamQueryLanguage parser (which is also used by Strigi). We’re now figuring out how to share our code in a more convenient way. Maybe we’ll use svn external…

Recently I’ve had a couple of ideas for a project (like I need another one of those). The goal would be to make a library which allows applications to easily track their user’s interactions and log them in a central location. Project maintainers/contributors could then look at the collected data to help them make decisions about what they should be spending time on. For instance, a media player might log what types of files are played or if it was synced to an iPod-like device.

As far as technical hurdles go, doing something like this is pretty easy. The main questions I have are around the kind of policies that should exist for such a thing. Obviously, participation should be opt-in. But should it be on a per-app basis, or per-user? Or both? If it is per-app, you would likely get bombarded with a prompt on the first run of every app that uses this system. If that is a small number it might be ok, but hopefully that wouldn’t be the case :). On the other hand, maybe you don’t want certain sensitive applications (email client?) ever sending info.

Then there’s the question of who should have access to the data. My feeling is that the user should always be able to see everything that he has sent. But should he also be able to see everyone else’s individual data? What about the aggregated data? That leads me to the next question. Should there be a cookie that identifies a single user throughout all applications? Or even a cookie per-application? I think having a cookie across all applications would definitely make the data more useful, but I’m not sure if people would be opposed to such a thing. Of course, this leads to yet another question. How do we keep personal information out? I don’t believe there is a technical solution to keep things like this from making its way in. Developers will need to be very careful, and that kind of bothers me. If all of the data on the server is available to everyone then maybe public scrutiny will help keep things in check, but who knows.

These are just a few of the questions I have come up with, and I am sure others can think of plenty more. Is it possible to come up with something that benefits the development community without infringing on user’s privacy? Even so, would users participate? Comments are open.

Surprisingly enough, no one has flamed me yet for being disappointed with the quality of KDE 4.0. I must try harder. I used to be able to attract flames much more easily.

Well, I've had KDE 4.0 on my machine for a day or so now, and I'm getting used to it. I've switched to running AIGLX so that I can use KWin's OpenGL mode instead of the XRender mode, and it's a lot more stable, although I can't run Google Earth any more. With the OpenGL rendering, the desktop look great, and the beauty of the desktop alone is probably enough to stop me switching back to KDE 3.5 at the moment. A few times I have clicked on a window only to have it completely disappear without warning - not sure what that's about. There are a few niggling little bugs in the behaviour of a few things, but I'm sure they'll get sorted in a minor release before too long. (Such as icon widgets not working with a graphics tablet, not being able to hide the plasma blob, konqueror not loading images or styles, etc.)

I am inspired to try writing some plasma applets to do things properly. And when I say properly, I mean how I want them to work. I've had a look at some of the source for existing stuff, and it looks relatively easy, so instead of writing any more of this, I'm now going to go off and write some code. Perhaps. If I can stop gazing at the beautiful desktop.

So, KDE 4.0 is out, and I have installed it on my computer. I've had it on there for a while actually, in one form or another, but this is the first time I've used the actual released version, and the first time I've logged into my main account using it.

And what are my first impressions? Well, the first impressions are that it has, again, improved over the previous pre-release. A nice new wallpaper, a slightly sleeker panel, and a number 4 instead of a 3.97 or something.

My second impressions are that it's still very unstable, very unpolished and, to be honest, somewhere between an alpha and a beta in quality. I had been expecting the lack of features, as that was well advertised, but I had at least expected the released features to work. Anyway, I'm going to stick it out - it's going to stay on my computer for the next week at least, and I'll start writing bug reports., and looking forward to 4.0.1, or whatever comes next.

Just giving more voice to original announce: Tomorrow, Saturday 12 January, at 17 UTC an irc meeting will take place on #strigi channel (it’s on freenode if you don’t know).

During the meeting Strigi developers will discuss about the future developments of Strigi.

Special guest: Aaron Aseigo. You’re all welcome.

As you may know, KDE4 will use Strigi for meta information extraction instead of the old KFilePlugin classes.

Since Strigi’s analyzer work in a different way, lot of code has to be ported. Unfortunately, after a good start, some relevant analyzers were still missing.

But in the last weeks Strigi gained support of:

• wave file
• avi files
• txt files
• dds files
• rgb files
• sid files
• ico files

I’ve also updated this summary page. As you can see there’s still some work to do, but don’t worry… I’ll try to do the best ;)

Why I waited so long to install flashblock I may never know. But I'm glad I finally did.