If you're a developer interested in RSS in KDE (and maybe you are at GCDS right now), please scroll to the end.

Akregator development was slowed down for quite some time: The development team was basically reduced to one person, me, and I had not much time for it. That's why Akregator only slowly recovered from porting regressions introduced during the KDE4 port. Also, the article storage layer showed its limitations (see startup time and memory consumption) and the metakit backend implementation lacks robustness, thus it became clear that something must happen to make both the user experience pleasant and hacking Akregator fun again. Another long outstanding wish of mine was to decouple feed list handling and item storage from the core Application to a central desktop service, to make both accessible to other applications without the need to run Akregator.

Nowadays, the natural choice to achieve al this is to use Akonadi (although the idea was already in my head, before Akonadi even existed, I think). Luckily, Dmitry Ivanov came along and implemented RSS support for Akonadi (SVN, Dev-Wiki) as his last year's GSoC project.
It's currently going under the working title "krss" (we're still looking for the final name, so let the suggestions come). krss currently comes with two Akonadi resources (local feed list and one syncing with the Newsgator online reader) and libkrss, a client library for convenient access. There is also a little RSS reader, krssreader, which serves as demo application.

Dmitry did an excellent job here with designing and implementing krss, and also giving feedback (and sometimes debugging) to Akonadi. And, at least as important, he sticked around and now a year later, we decided that to go forward, stay motivated and to get to the real world usage scenarios, it's time for porting Akregator to Akonadi/krss, improving krss while doing so. We started with that a few weeks ago and to my own surprise, this went quite smoothly so far. After a weekend, we had the basics ported and most of the old Feed and Article classes removed. Now, the port is already usable for feed reading (for certain definitions of "usable", that is). Data migration from Akregator also works, even if importing large Akregator archives shows some performance issues and the need for some more optimization sessions. Here's the mandatory screenshot:

Doesn't look too exciting? The UI of course didn't change much while porting, the only notable change there is that krss doesn't group feeds in hierarchical folders but in a flat set of tags: Every feed can have n tags assigned, and the pseudo-tag "All Feeds" lists all of them.

So what are our plans with krss?

• KDE 4.4, definitely: Finish the Akregator to Akonadi port and make krss ready for prime-time. The goal is to have all current Akregator features supported by 4.4.
• KDE 4.4, if possible: move libkrss to kdepimlibs. This is needed to have applications outside of KDE-PIM use krss. As this implies keeping a stable and binary-compatible API, we will do this only for 4.4 if we think the API is ready.
• Port applications, write new ones, add more shiny features.

Moving RSS handling to Akonadi, krss could help to improve the "RSS experience" for all of KDE by sharing feed list and item storage within existing applications such as Amarok, KTorrent or RSSNow! or easily writing new ones, e.g. a Konqueror plugin or a dedicated stand-Podcast client. Integration of RSS-enabled applications in KDE could be vastly improved, a topic deserving at least another blog entry. Its also time to reach out to the developers of applications like the ones mentioned above to find out what's missing to fullfill their needs.

If you at GCDS and either working on an existing application using RSS, or have interest in krss and Akregator, just poke me. Or mail me, but it might take me some time until I read it). Depending on the interest, I might also set up a little BoF/informal meeting at the beach during next week. If you're not at GCDS, you are of course also invited to join the fun. It's the perfect time to get involved and make krss and its apps rock.

Want to see how to crash almost every KDE application?

• In your favorite KDE application, open any modal dialog, e.g. the configuration dialog.
• Quit the application using D-BUS, like this:


qdbus org.kde.kontact /MainApplication quit


Chances are high that your application just bit the dust and you're greeted by Dr. Konqui.

Why does it happen? Well, let's have a look at how modal dialogs are usually created. Most often applications have some "main widget" with slots reacting to user actions, creating a modal dialog on the stack, like this:


void ParentWidget::slotDoSomething() {
SomeDialog dlg( this ); //the dlg-on-stack-variant
if ( dlg.exec() == QDialog::Accepted ) {
const QString str = dlg.someUserInput();
//do something with with str
}
}


What could possibly go wrong here? Nothing, you might say. Looks safe, right? This code is so trivial and the pattern is used in so many Qt and KDE applications. Wrong! This code is bound to cause a crash in a couple of situations, where a D-BUS call to quit() is only one of them (and a somewhat esoteric one, admittedly). Why?

While dlg.exec() is executed and the dialog is shown, your application returns to the event loop and processes any event that comes along. Which means, that anything might happen before exec() returns. Right. Anything. In the usual case, the user enters something and then presses either OK or Cancel to close the dialog, and exec() returns. He can't to anything else, as the parent widget is disabled anyway, as the dialog is modal. But in most non-trivial applications, there are more things going on: Asynchronous background jobs might complete, e.g. Konqueror might finish loading a website and replace the currently displayed Kate KPart while you're in its print dialog configuring your printout. KMail might start an interval mail check while a (modal) KMessageBox still tells you that it couldn't reach your mail server last time. Or something is triggered by a D-BUS call.

That's fine most of the time, unless in the following case: The background operation/d-bus call triggers the deletion of the dialog's parent, the ParentWidget instance which created SomeDialog dlg in its slotDoSomething(). When the ParentWidget is deleted, dlg is deleted in turn, as it's the child of ParentWidget. Thus when exec() returns, we are in an awkward situation: The execution of the parent widget's slotDoSomething is continued, although "this" is already deleted, and so is dlg, which was created on the stack (!). Access to a member variable of the parent widget will crash the application, and if not, it will crash when leaving slotDoSomething, as it tries to destroy the dlg object a second time when unwinding the stack. Booom.

KDAB and the FSFE Fellowship Group Berlin invite you all to celebrate the 4.2 release with us.

Date: January 28th, 2009 (Wednesday)
Time: 20:00
Place: KDAB Office Berlin, Adalbertstr. 7/8, U Kottbusser Tor (map)

If you want to join us, please send us a mail to kde-release-party@kdab.net, so we can plan accordingly.

As Roberto blogged about how he converted his blog into a blog/podcast hybrid using Talkr, I thought I should tell you about a well-hidden, half-finished feature in Akregator: Basic Text-to-Speech support.

To use it, you need kttsd installed and set up, which does all the heavy lifting for Akregator.

After you have got it running, start Akregator and enable the speech toolbar (Settings->Toolbars->Speech Toolbar in the menu):

Now, just select the articles you want to have spoken and click the parrot to enqueue and play them.

Isn't that great? All the people on PlanetKDE are podcasting to you now!

As it turned out yesterday, even ferrets like KDE:

But unfortunately they make KDE apps crash sometimes, so KDE can't be certified as ferret-proof yet. Which brings us to the fact, that the research field of animal-centric computing was neglected for too long. What tremendous opportunities we have here! Just compare the numbers: There live trillions of animals on planet earth, where the homo sapiens population is ridiculously small. You can't seriously talk about world domination if you don't take this into account.

And yeah, know your user!

Ok dudes, now I finally started a blog at kdedevelopers.org. Working on Akregator, a tool that many people read blogs with, I am not really an early adopter when it comes to blogging myself ;-). Well, there is the Akregator blog where we blog from time to time what's going on in Akregator development, so check this out if you're interested.

I look forward to the NL-PIM meeting taking place next week in Annahoeve, Netherlands. It's the first time I actually meet the PIM people. In the last days we were thinking about adding more sophisticated search and filtering functionality to Akregator (maybe using something similar to the labels in GMail). So the challenge is to come up with a concept that is a) powerful and b) easy to grok and use. It might also make sense to have a KDE-wide solution for KDE4, instead of an isolated Akregator-only "we do it all the other way and confuse people" approach. Labels could be stored using Tenor (still waiting for the prototype, Scott ;-) ). I will discuss this on the PIM meeting (having usability people there is really a good thing) and hope that things get clarification.

P.S.: Tomorrow my CVS/SVN account gets one year old. Time for a little birthday party ;-)