open source stuff

Archive for the ‘Nepomuk’ Category

KDE Telepathy 0.1 – Part 5 of 5 – The Future

Posted by grundleborg on August 7, 2011

In the final part of this mini-series to mark the first Technical Preview release of KDE-Telepathy, I’m going to outline a little bit about the future.

Our immediate plans are further stabilisation. We’ve already received a fair few bug reports and feature requests, and we expect to receive many more. We’ll try to fix as many of these as we can and hopefully put out a 0.2 release in the next couple of months. I’ll leave it to our newly appointed “Release Manager” to announce exactly when this will happen.

Those of you who have been following the blogging and development around KDE Telepathy will probably be wondering what happened to all the Nepomuk integration. Lots of it is already implemented and here at the Desktop Summit I’m adding some final polish and performance improvements to it so that it will be usable soon. Expect the beginnings of this to land in an 0.3 release, at an as-yet-undefined point in the future. This means MetaContacts (or People as we prefer to call them) will not land in the next release but should be present in the one afterwards.

Posted in Collabora Planet, Collabora Web Site, KDE, Nepomuk, Telepathy | Tagged: , , , , | 8 Comments »

KDE-Telepathy – A Vision for Integration

Posted by grundleborg on April 26, 2011

The first preview release for KDE-Telepathy is getting closer. Our release-tracker bug now only has 9 bugs blocking it and many of these already have patches on reviewboard. Our first release will be made separately from the KDE Software Compilation, and should be compatible with installs of 4.6.x or trunk. It will be suitable only for people who like to try out new technologies before they are ready for the mainstream. It will not be feature complete (although we hope many of the basic features will be implemented). It will not be polished (although we do want to know about any bugs or issues you find – that’s why we’re making this release). It will also not be especially deeply integrated with the rest of the KDE S.C. or the Plasma workspaces. There will be a plasma applet for bringing accounts on and offline, but the rest of it is much like a traditional Instant Messaging application.

With expectation management out of the way, let’s take a look at how KDE-Telepathy is going to be in a few releases time. The biggest change from traditional IM clients is that Telepathy is all about Integration. Why should you have a standalone IM client? Real-time Communication and Collaboration features should be available where you want them regardless of the artificial boundaries between applications. Telepathy’s modular architecture of components communicating over DBus enables this to an extent never before possible.

Let’s take a look at the typical uses of Telepathy’s features and how they will work with KDE-Telepathy (not all of what you see below is being implemented presently):

  • Bringing Accounts on/offline, setting presence and status messages: this will by default be handled by a Plasma applet, although integration with other parts of the workspace could be carried out as appropriate (I’m thinking of that “me menu” concept from Ubuntu as an example).
  • “Currently Listening To: Foo” in the status message: this would be set by a plugin for the music player being used which updates the Telepathy presence message.
  • Configuring your Jabber/MSN/SIP/etc accounts: handled centrally in some kind of “My Identity” SystemSettings KCM.
  • Starting a chat/call: can be done anywhere that knows about people – plasma applets/KAddressBook/Tradtional “Buddy List” app/etc. There is a Summer of Code project to do some work on this stuff in Plasma and another one to make it possible in KAddressBook.
  • Collaborating on a Text Document: inside Calligra, or any other document editing software.

The key point of all this is that there will be no KDE-Telepathy Application as a single point of interaction for users. In reality, the features of KDE-Telepathy will be integrated with the rest of the KDE experience. The end result – features in more natural and useful places and a more seemless experience for our users.

Once our users stop knowing the name of KDE-Telepathy and start to see it as simply some communication/collaboration features that are always there, that’s when I’ll consider the KDE-Telepathy project to be a success.

Posted in Collabora Planet, Collabora Web Site, KDE, Nepomuk, Plasma, Telepathy | Tagged: , , , , , , | 17 Comments »

The Vision of KDE-Telepathy: Part 3 – The Implementation

Posted by grundleborg on April 3, 2011

This article is the final part in a series of 3 articles (Part 1, Part 2) covering the vision and high-level design decisions of the KDE-Telepathy project. It is highly recommended that you read Part 1 and Part 2 of this series before this part, as it won’t make as much sense without them.

Now that Nepomuk has been identified as the solution to our problem, we should address how to implement KDE-Telepathy with that in mind. The diagram below shows very roughly the architecture of our system.

The Telepathy Framework interfaces with Nepomuk, and the user facing applications interface with Nepomuk. This allows Telepathy data, such as presence and message history, to be consumed by applications which know nothing about Telepathy, simply by retrieving the data from Nepomuk. There are two areas in which infrastructure must be developed: between Telepathy and Nepomuk (Service Side) and between Nepomuk and the User Facing Applications (Client Side).

Service Side Infrastructure

The main component on the service-side (between upstream Telepathy and Nepomuk) is the Telepathy Nepomuk Service. This is a daemon running in the background that is responsible for keeping all the basic Telepathy data synchronised into Nepomuk (including your own presence status, and your server-side buddy lists and their presence statuses etc). This service ensures that Nepomuk always holds up to date and accurate data from Telepathy.

Client Side Infrastructure

On the client side, although applications can access the Telepathy data directly from Nepomuk, a library, telepathy-kde (still in the early stages of development) exists whose purpose is to abstract away much of the complexity of writing applications that are Telepathy aware. Its purpose is to provide easy to use classes, models and UI widgets for contact lists, starting and handling channels, text/voice/video chat UI components and everything else commonly needed for adding Communication and Collaboration features to KDE applications, correctly integrated with Nepomuk.

Of course, there are many other components to the Telepathy-KDE project, Telepathy being a DBus centric framework leads to a large number of separate components (a topic for another blog post some day), but only those components directly related to the use of Nepomuk have been presented here.

Posted in Collabora Planet, Collabora Web Site, KDE, Nepomuk, Telepathy | Tagged: , , , , | 11 Comments »

The Vision of KDE-Telepathy: Part 2 – The Solution

Posted by grundleborg on April 2, 2011

This article is Part 2 in a series of 3 articles (Part 1) covering the vision and high-level design decisions of the KDE-Telepathy project. It is highly recommended that you read Part 1 of this series before this part, as it won’t make as much sense without it.

The answer, of course, is Nepomuk. It’s a generic storage place for information, it doesn’t require an application to speak the Telepathy and KMail APIs in order to get data about people, and its already a part of the KDE Platform, meaning it has widespread adoption in KDE applications. Perfect. And the best bit is it already exists. There are few things more satisfying than finding a massive, fundamental problem you face has already been solved.

However, Nepomuk can only truly work if everyone uses it. The more that KDE applications make use of Nepomuk, the more the benefits of that usage increase for our users. KDE-Telepathy alone making use of Nepomuk is a start, but we need to see those other applications that were mentioned in Part 1 making use of it too. That way, all the information related to people will be centrally accessible by any application, making the sort of unified approach to information outlined in our vision become possible.

The Hard Dependency

There are inevitably some people who will now ask “What about users without Nepomuk?”. KDE-Telepathy has a hard dependency on Nepomuk. We are trying to build a better user experience for the future, not just reimplement the same old Instant Messaging applications of the past (I have nothing against the applications like Kopete and Pidgin, it’s just that I believe we have a chance to make something new and considerably better). As I hope you will have gathered from Part 1 and this blog so far, the purpose of this project is to create a unified experience, and for that, we need a framework like Nepomuk. Making Nepomuk optional would mean making the entire goal of the project optional, which is a completely pointless move. Making some other fallback technology to replace Nepomuk when it is not present is equally fruitless, as I hope I made clear in the penultimate paragraph of Part 1.

To those who say that Nepomuk is slow/bloated/$negative_adjective_of_choice, I say this: it has improved massively since it was first introduced, and our experience has shown that making use of Nepomuk is the best way by far to make it improve further. The areas of Nepomuk used by KDE-Telepathy have improved dramatically due to our feedback and involvement with Nepomuk developers. So, if you feel like complaining about Nepomuk, instead, put your time to better use and file some bug reports. We did. That way, the problem might actually get fixed.

Tomorrow brings the final part in this three-part series on KDE-Telepathy, in which a high-level overview of the design of KDE-Telepathy with regard to Nepomuk is presented.

Posted in Collabora Planet, Collabora Web Site, KDE, Nepomuk, Telepathy | Tagged: , , , , | 27 Comments »

The Vision of KDE-Telepathy: Part 1 – The Problem

Posted by grundleborg on April 1, 2011

This article is Part 1 in a series of 3 articles covering the vision and high-level design decisions of the KDE-Telepathy project. Recently we have gained a large number of new developers in the project, which is absolutely fantastic, but this has made one major weakness of our project become apparent. It has existed for over 3 years now, but we don’t have any written record of why we are doing things the way we are. This series of blog posts is an attempt to rectify that.

Background: Interacting with People

When using a computer, we often need to interact with one another. We do this in many different ways. Let’s take a list of just a few fairly diverse examples:

  • Chatting with my friends
  • Video Conference with my Team at work
  • Emailing my family from time to time
  • Looking at the hilarious photos of cats that my friend keeps sending me
  • Working on a project description document with my work colleagues
  • Looking at my friends’ holiday photos

As you can see from that list, there are a huge range of different contexts in which we interact with other people. Sometimes we want to communicate with them, as illustrated by the email, video conference and chat examples. Sometimes we are looking at stuff that came from them, such as the lolcat pictures. Sometimes we are working together on something, such as the project description, and sometimes we have something that is connected to them, such as the holiday photos they are in. The one thing that all of this has in common is that there is information to do with people.

Despite this information coming from a range of different sources, to me, as a human being and a computer user, it is all fundamentally the of the same type, so I would expect the information to all be accessible in the same place. Photo tagging, chat history, collaborated documents, files I got sent – they could all be related to the same person, so my computer should treat them as such. Think of the Facebook friend feed – all the information about a person, whatever its source and whatever its purpose, is presented in a single unified place. The reason: because it’s all about the same person. The rest is just implementation detail, and as all programmers know, user experience should never be dictated by implementation detail.

The Problem: Disparate Technologies

Now that we have developed this fundamental vision, lets take a look at the problems we are going to face living up to the statement at the end of the previous section – namely not compromising the vision because of implementation difficulties.

The problem is this: while all the information about people described above seems fundamentally the same from the user’s perspective, in the KDE Software Compilation, different aspects are handled by completely separate applications or frameworks. Email could be handled by KMail, Real-time communication can be handled by Telepathy, Photo tagging can be handled by Digikam and so on.

What can we do? There are several different ways of approaching this problem. One tempting solution that may present itself to the armchair API designer might be to build an API to unify all this information about people. But then that would require KMail and Digikam to be rewritten to make use of this new API. A massive, not to mention entirely impractical and undesirable task. Perhaps instead we should create some interfaces for the applications to share information with each other? This sounds OK to begin with, but then imagine we used Mailody, Gwenview and Kopete instead – they would need to support these interfaces too (as would every other application we could replace these with). And what if there was a desire to make some other related set of data link together across applications? Then we’d need another set of interfaces and we’d have to modify all the applications all over again. Another unsustainable proposition.

What we really need is a central store for this kind of information. It should be supported by all KDE applications, but it should not be necessary for applications to support each other’s underlying libraries and frameworks to make use of the data. It should be capable of storing not just information related to people, as concerns us here, but also information related to anything else, so that there is no need to create another new solution should other genres of application decide that valuable information can be shared between each other.

Tune in again tomorrow for Part 2 in this series to find out the solution to our problem.

Posted in Collabora Planet, Collabora Web Site, KDE, Nepomuk, Telepathy | Tagged: , , , , | 5 Comments »

Telepathy Contact List Update

Posted by grundleborg on March 24, 2010

A while ago I wrote about the Realtime Communication project – to integrate the power of Telepathy into KDE. I thought it was probably time to write a little update, so without further delay, here’s a screenshot of the Contacts List.

Telepathy Contact List Screenshot

So, what’s new?

  • Icons indicating the presence status of contacts
  • Groups! These are synchronised with the server where the IM protocol supports it.
  • Meta contacts – these are not fully implemented yet, but the little + signs next to each contact in the list show they are partially there. At the moment, fake meta contacts are created for all contacts, but support is nearly complete for real metacontacts where the user has indicated two contacts belong to the same person.

Meta contacts in particular are exciting because they use Nepomuk’s PIMO ontology, meaning that they are accessible not just to Instant Messaging applications, but can be used by any Nepomuk enabled app.

That’s all for today, but hopefully I’ll have more exciting stuff to report on soon (no promises, because I’m planning on writing unit tests for what we have so far before I implement any more new features).

Posted in Collabora Planet, Collabora Web Site, KDE, Nepomuk, Telepathy | Tagged: , , | 5 Comments »

Announcing the KDE Real-time Communication and Collaboration Project

Posted by grundleborg on February 23, 2010

Hello World! It’s been a long time since I last wrote anything here, and for that I’m sorry. The autumn was consumed by university work, and the last few weeks I’ve been discreetly coding and writing to get everything ready for this announcement. Anyway, without further irrelevance, let me present the KDE Real-time Communication and Collaboration Project. You’ve probably heard me blathering about Telepathy before, but now for the first time we have a coherent plan for world domination, concocted by Abner Silva, Matt Rogers and myself (with help from many other people).

Let me briefly introduce the project and our aims:

  • Fully integrate real-time communication (think VoIP, IM, Video etc) into the KDE Plasma Workspace (do I have the branding correct?)
  • Provide a fully-featured Telepathy-based real-time communication experience in the KDE SC. (loving the double-barreled words)
  • Provide infrastructure for collaborative features in KDE SC applications.

So, if any of this interests you, we’d love your help. Hop in to #kde-telepathy on freenode IRC, or join our mailing list.

And, while you’re at it, why not take a look at our code so far.

The Code So Far…

Warning: this is highly experimental code which may cause all kinds of side effects, especially the Nepomuk related stuff, which is likely to make a complete mess of your Nepomuk database, so use with care.

If you’ve read the above warning and want to take a look at what we’ve done so far, here are some instructions. For the first phase of this project, our attentions are focused on building Telepathy based components for basic IM usage on top of the existing Kopete codebase. So far, you can create an account (Jabber is the only kind tested, so expect minor bugs with other protocols), set its presence and see a list of your contacts. Not the most exciting stuff ever, but with this core stuff in place, more features should arrive very soon.


You need recent telepathy-mission-control-5, telepathy-gabble and telepathy-qt4. Best to install these from your distribution. If telepathy-qt4 is not provided, or older than 0.2.0, then download the source here.

The Account Management GUI

Checkout and build the account management gui from svn here:


Also install its plugins from


You can launch it by running:

kcmshell4 kcm_telepathy_accounts

And then follow the wizard to set up your Jabber account.

Setting the Account Presence

To set the account presence through a GUI (ie. bring the account on/offline), you will need the presence plasma dataengine and applet, available again from svn:


You can then add the applet to your Plasma workspace and use it to bring the account(s) created with the GUI in the previous section on/offline.

Nepomuk Integration

Your contact list is integrated into Nepomuk by means of the telepathy-integration-daemon. Best to install it and launch it before bringing any accounts online. Code, again is in svn.


You can run it by calling telepathy-integration-daemon on the command line.

Contact List App

Finally, in order to see our contact list, we need a contact list app installed. Currently, this is in the very early stages of development, but you can at least see a list of contacts in it (although you can’t interact with that list yet). Source code is at:

svn:// (corrected)

and you can run it by calling telepathy_contactlist_prototype on a command line.

If you like what you see or have any problems with getting it working, come talk to us in #kde-telepathy. We’re very happy to help out 🙂

Posted in Collabora Planet, Collabora Web Site, KDE, Nepomuk, Telepathy | Tagged: , , , , | 21 Comments »

The Nepomuk Sprint

Posted by grundleborg on June 22, 2009

I’m writing this on the plane back from Freiburg, and the Nepomuk Coding sprint. It’s a beautiful town (except late at night during the weekend, but anyway…) and well worth visiting again (hopefully there’ll be a Nepomuk Sprint 2010).

Now to the important details. As I often seem to at these kind of events, I find myself leaving with less code written than I arrived with. However, when put in context, this is no bad thing. Nepomuk is a new technology, and is not entirely straight forward for a newcomer to understand. I arrived with intentions of integrating Telepathy with Nepomuk, but with little clue how to actually do this. And the results: I know understand enough about how Nepomuk works to make a plan, and start coding on integrating with Telepathy (unfortunately most of the code I wrote in the few days beforehand with this aim turns out to be so wrong it’s best just to throw it away and start again).

There are two ways in which Telepathy will be integrated with Nepomuk. One is the fairly obvious case of storing metadata about your IM buddies. Some examples of this might be: the last time they were seen online or the geolocation at which they were last online using the Location interface of Telepathy). I’d love to hear any more suggestions of metadata that it might be good to store on your instant messaging and VoIP contacts (please use the comments section at the end).

The second integration point is a little different. It concerns the idea of metacontacts. Users of IM clients such as Kopete are probably familiar with the idea that you can group two buddies on different protocols, who are the same person in real-life, together as one metacontact. I intend to implement this for Telepathy applications’ contact lists using Nepomuk to store the relation between the different buddies. The advantage of doing this is that not just your IM client, but any Nepomuk enabled application can see this relationship.

So, that’s my rather superficial hand-wavy summary of the plans that came out of the Nepomuk sprint for Telepathy. I hope to write again soon to provide a mercilessly technical explanation of how all this will/is being implemented.

Finally, I’d just like to say thank you very much to Sebastian Trueg who did such a great job of organising this sprint.

Posted in Collabora Planet, KDE, Nepomuk, Telepathy | Tagged: , , , , , | 6 Comments »

Telepathy-KDE update

Posted by grundleborg on June 18, 2009

I haven’t written anything for a couple of months now for the same reason that I haven’t committed any code. Exams. Now they’re over it’s back to hacking. But just because I haven’t been working on Telepathy/KDE for a while doesn’t mean that nothing has been done (obviously).

The underlying TelepathyQt4 library on which all our work is based has progressed a lot, gaining support for requesting channels from the Channel Dispatcher, gaining the Client interfaces and going through what will almost certainly be the last major API redesign before it goes stable. These two advances mean that it is now possible to work on Telepathy client applications in Qt/KDE without having to play an endless game of API catch-up.

There are also two summer of code projects progressing nicely:
George Kiagiadakis (gkiagia)’s work on KCall is really exciting… I can’t wait to take part in my first video conference using KDE software!
Kaushik Saurabh (roide) is also making great progress on his Conversation Logging Framework for KDE (while not entirely a Telepathy project, it goes without saying that the two will be integrated).

And now to the future… to Friday. I’ll be at the Nepomuk Sprint in Freiburg working on integrating instant messaging buddies with the address book and the semantic desktop. I’m not yet exactly sure how this will be done, but I’ll be spending the next 2 days up until the sprint getting that nailed down, and then coding madly once I get there. I really hope there can be something photogenic as a result, since libraries provide very limited picture-potential for this blog.

Posted in Collabora Planet, KDE, Nepomuk, Telepathy | Tagged: , , , , , , , , | 4 Comments »