Season of KDE 2006

A Season of KDE 2006 project by Luke Alan Sandell
Mentored by Till Adam

Project Details

Currently there are three separate programs for reading "push" content in KDE: KMail for email, KNode for Usenet news, and Akgregator for XML feeds (I use the generic term "feed" in this document to refer to any type of XML syndication format, which mainly includes RSS and ATOM.). In this proposal I demonstrate the advantages of having a single program for all three activities, and I give a high-level description of how I would implement such functionality.

Because of the similarity in functionality between KMail, KNode, and Akgregator, it makes sense to merge them into a single application. Kontact does this somewhat inadequately by allowing the user to quickly switch back and forth between the three applications' respective KParts, but this is disorienting and also results in an inconsistent user interface. My plan is to have KMail allow accounts for different Usenet servers and a single account for all the user's XML feeds. As a "proof-of-concept", one can look to Mozilla Thunderbird, where these three functionalities have been successfully integrated into a single application.

The reason I want to extend KMail rather than KNode or Akgregator is that KMail already supports different types of accounts. Adding a new type of account is only a matter of subclassing KMAccount. Usenet and XML feed accounts would store their messages separately from the Local Folders, similarly to how IMAP accounts store theirs now. I realize that I will have to make modifications to other parts of KMail in addition to extending KMAccount. For instance, I will have to cause the message composer to accept newsgroup names in addition to email addresses. I will fortunately be able to make heavy reuse of code from both KNode and Akgregator. That is another key advantage of combining these three applications into one; it increases the possibility of code reuse.

Currently the different subclasses of KMAccount are linked directly into the KMail library. In my opinion, this does not follow the loosely-coupled component architecture that makes KDE so powerful. I would create a new "service type" for KMail accounts that would allow them to be dynamically loaded via KTrader. That way, if at some point in the future a new type of account comes into use, a corresponding module can easily be created by a third party and included into KMail without the need to recompile the entire application.

Because I want my project to be something that is useful in practice, I hope to do my coding against the KDE 4 development tree. This will not be a problem, as I routinely check out and build KDE from the Subversion repository. I realize that the Akonadi PIM storage service is not yet complete and that any code written without Akonadi will probably just have to be rewritten for KDE 4. That is why I am willing to work on bringing Akonadi up to speed if the need arises. Being a very abstract thinker, I enjoy the challenge of creating APIs that will be of maximum utility to other developers.

As I am planning to work on KDE 4, it makes to use Qt 4's new model-view architecture. Indeed, I think the very first thing I should do is create an abstract model and view for KMail's message list. That way, it will be easier to extend it to view a list of Usenet messages or feed headlines at later date.

Deliverables

• KMail will use Qt 4's Model-View architecture for its message lists.
• KMail will dynamically load its account classes as shared library modules using KTrader.
• KMail will be able to read and compose Usenet messages.
• KMail will act as an XML feed aggregator and reader.

[ Edit ]