All Unkept
Posted in: KDE, Rants, Linux  —  June 17, 2010 at 01:57 AM

Leaving KDE

by Luke Plant

After being a loyal fan of KDE for a long time, I've just switched to GNOME.

I'm afraid to say that since the KDE 4 series, I've been unable to recommend KDE to anyone. With KDE 4.0 to 4.3, that was due to general crashiness, brokenness and bugs that are at the level of embarrassing — when a bug is obvious enough and significant enough that a new user would be shocked to find it and I would have a hard time explaining how I could use software that is clearly inferior to whatever they were using before (usually Windows).

With KDE 4.4, most desktop instability has been ironed out, but it has been replaced by problems that mean I can no longer stomach or risk staying with KDE for myself, let alone recommend it to anyone else. The final straw was that the framework for storing PIM data (Akondai) is turning out no better than I feared and is ‘losing’ some of my data.

I found that some things added to the address book ‘never’ actually end up in the file they are supposed to be stored in. I've added an e-mail address for a contact, and it appears to have added fine in KAddressBook. The data persists even across reboots etc., so it isn't ‘lost’ in one sense. Usually, the data appears in my std.vcf after a few seconds. In this case, however, four days later it still hasn't appeared in std.vcf. That counts as close enough to ‘never’ in my book, so it is fair to say it is ‘lost’. This has happened intermittently since KDE 4.4.1.

One additional result of this is that KMail never sees that address — at the moment it seems that it looks only in std.vcf, not Akonadi (and this is probably the only reason I found the bug in the first place). That's a pain, but the more serious problem is that my data is just not where it is supposed to be. If I need to backup and restore, I imagine it would be possible for that to succeed, if the Akonadi data was backed-up and restored along with the underlying data. But if you get that bit wrong, I can only imagine a world of pain and subtle data corruption. It is completely unacceptable that my data is being stored in “my data files + completely opaque Akonadi database” rather than just “my data files”.

Another bug is that the Google contacts Akonadi plugin also loses data in a serious way, making it far worse than useless. The nature of this bug makes me think that either there is a significant bug in the Akonadi framework, or that the framework API made it is easy to get this wrong — both of which are worrying.

These bugs are on top my general concerns with the framework — it has always been painful to work with, and the fact that it is even visible is a major failing — the software layer it replaced was, after all, completely invisible, just as it should have been.

From what I can tell, migration of KMail to Akonadi is going ahead at full pace and will be mandatory soon. My contact data is modest (500 Kb), so I have been able to cope with moving it around and fixing some problems, including some data loss and mistakes caused, I think, by the above bugs, since backups are quick. But my e-mail data is 2.5 Gb, and detecting problems or errors is going to be massively harder. I'm not willing to risk my e-mail data with Akonadi, so I need a new e-mail client.

It turns out that Evolution works for me. It stores data in mbox files, which isn't my preferred (1 file per e-mail, like maildir or MH, is nicer for various purposes), but it is a standard format, and since my backup tool is 'diff' based it will still cope efficiently with it. It even integrates with Google contacts out of the box, and the calendar app integrates with Google calendar, while allowing me to work offline. This is what Akonadi is supposed to offer one day, and I wish them the best of luck with that. But for now I'm going to stick with a system that prioritises the safety of my data, and that I know works. Evolution has a few significant niggles, but I think I can live with them.

That leaves me with the choice of desktop. Using programs from one desktop suite generally is faster and easier and looks nicer. I had already dropped Konqueror for Chrome (Konqueror has fallen far too far behind these days), and GNOME equivalents to most KDE apps work well enough — like Empathy/Pidgin. That tips the balance over to GNOME — and I can still use apps like k3b for specialist work when I need them.

Most of my reasons for leaving GNOME in the first place (about 7 years ago I think) have been resolved. GNOME apps like Nautilus and Evolution are no longer as excuciatingly slow and bloated as they used to be (and I don't think it is just that my computer got faster), and actually feel quite snappy most of the time. In some cases they definitely outperform the equivalent KDE default app (e.g. Eye of GNOME is very fast and works very nicely, doing 90% of what I used Gwenview for before, but much faster). Generally GNOME is much snappier as a desktop — it takes only about 5 seconds to start after I've logged in, which is much faster than KDE.

So I'm using Ubuntu's GNOME desktop, and I no longer have plasma and all the plasmoids. To be honest, I don't think I'm missing them. I have all the panel applets I need, and they are well designed and work properly. Proliferation of plasmoids is like the proliferation of apps on Apple app store — most of them are not worth having, and having to search through to find the ones that are is an anti-feature (not to mention that the new horizontal applet picker in KDE 4.4, which replaced the vertical one in KDE 4.3, is just awful — I don't understand how such a major regression happened).

I certainly won't shed a tear over Nepomuk/Strigi. After weeks of it constant disk activity as they attempted to index my files, they never seemed to do anything useful. They have been replaced by Tracker, which works very well, and very quickly, and without being a huge resource hog. It does not update immediately when I add new files, but it is fast enough to know that when I really want to find something in a real situation, it is likely to be in the index already. And it isn't the massive resource hog that Nepomuk was.

First experience with Ubuntu's GNOME has thrown up some problems. Here are some niggles I've been able to fix/solve:

  • PulseAudio - this breaks lots of things, especially games, and provides no added benefit. But it can be removed. Perhaps the Ubuntu guys will remove it in future, or make it easier to remove. Lots of people and programs seem to have problems with it, it's very difficult to see what value it is adding for most people.
  • To turn off desktop effects quickly (for better performance games) - either: install fusion-icon (use "fusion-icon -n" as the command) - or, to do it automatically for fullscreen games, set this option to true: /apps/compiz/general/screen0/options/unredirect_fullscreen_windows
  • To turn off screen locking on resume - there is setting is in gconf, search for 'lock'.

And here are some that are still bothering me a bit:

  • Reading new e-mails with keyboard only - it's a bit buggy/confusing with Evolution.
  • Some options are hidden away in gconf, so it's difficult to know if it is possible to change things.
  • GNOME has less configurability in general, or harder to get to it, especially for creating new keyboard shortcuts.
  • Compiz doesn't always seem to obey or understand all metacity options (e.g. shortcut for fullscreen-ing windows), so it sometimes confusing working out what is going on.
  • The GNOME file dialog boxes have improved a little bit since I was last using GNOME, but haven't begun to close the gap on KDE's far superior ones.

But there are some niggles which are no longer there due to the switch from KDE. Overall, things are similar at this level.

To conclude, I think the KDE developers were far too ambitious with the KDE 4 series. The cost has been that the only supported versions of KDE are ones that you cannot recommend to anyone, and that is a critical mistake in a competitive environment. Meanwhile, GNOME has massively improved in speed and has incrementally added features that people actually need, instead of creating large frameworks that may or may not be robust and useful one day.

Comments §

blog comments powered by Disqus