Tag Archive: telepathy

Video calls in KDE-Telepathy

Well, I think I owed you this one😉 Remember back in 2009 when I was working on KCall as part of the GSoC program? Well, it may have taken 2.5 years more, but I’m now pleased to announce that it’s finally in a ready-to-use state \o/ Don’t expect it to be perfect, of course. It still has a long way to go.

Here is the obligatory screenshot. Me on my desktop, calling myself on my laptop:)

Screenshot of ktp-call-ui

The KDE-Telepathy call-ui in action

A little bit of history

When my GSoC finished in 2009, there were 2 main problems with KCall. The first one was that the bits of the telepathy specification for doing calls (i.e. the “StreamedMedia” channel type) were problematic, not to mention that the API of the telepathy-farsight library, which was the only way to use StreamedMedia, was also weird and it took me too many tries to finally understand it (in late 2010…), which in simple words means that KCall was very unstable beacause it used the API in the wrong way (if there really was a right way to use it…). The second problem was that there was no telepathy integration in the KDE desktop, so KCall would need to have a proper contact list, account manager and other stuff that it shouldn’t have to implement.

In late 2010, the KDE-Telepathy project started evolving and we finally managed to make a first release last summer with the necessary components to use telepathy on the KDE desktop. At about the same time, work began on a new API for doing calls in telepathy, the so-called “Call” channel type, plus telepathy-farstream, the new and enhanced version of telepathy-farsight. It took a little longer than expected, but finally a few weeks ago, thanks to the awesome work of my colleagues at Collabora who engineered the whole thing, the “Call” API and telepathy-farstream were finished and released. Fortunately, last year I had already worked on porting the call-ui to the draft Call API, using the draft telepathy-qt Call bindings that used to be in the telepathy-qt4-yell module. So, now I only had to first update the telepathy-qt bindings to the latest and greatest API specification and then do the same with the call-ui, plus fix a bit the UI, which was way too ugly. And so I did.

The present and the future

The UI is far from perfect at the moment, but the engine seems to work reliably. I have many additions and improvements in mind. However, since I suck at UI design, I’d love having mockups of ideas from people that can actually design UIs. And I’d also love having other people to implement those ideas, since I’m a lazy man…😛 (ok, I don’t really mean that). So, if you feel like helping (either way), this is your chance to get involved😉

The current UI will be included in the next KDE-Telepathy release, 0.4, which is scheduled for next month. Be prepared.

Try it

So, if you can’t wait for the next KDE-Telepathy release and want to try this now, what you need is the latest ktp-call-ui from git master with all of its dependencies. To make a call, simply right click one of your contacts in the contact list and click “audio call” or “video call”. Alternatively, you can do this directly from the text-ui or the contact plasmoid. Note that older versions of those components also have audio/video call buttons, but they will try to start StreamedMedia calls instead, which will fail. Also note that calls require XMPP (jabber, google talk) at the moment, but SIP support is also on its way upstream.

So, last week we released the first version (technical preview) of Telepathy-KDE along with KDE SC 4.7. The release is separated from the KDE SC (it’s just a technical preview and hasn’t gone through kdereview yet), it just happened to be released at the same time. I would like to thank everyone in the team for making this release possible, after all those years that this project has been sitting there in playground, and especially David and Martin who did most of the hard work lately. If you want to try it, check with your distribution for binary packages or compile it from source (the source can be downloaded from here).

In other news, I am going to the Desktop Summit this year. See you all there:)

What is Telepathy-KDE

There seems to be a lot of confusion about what the Telepathy-KDE project is and what it has to do with Kopete. I’ll try and explain in this blog post everything, so that it is clear to everyone.

First of all, Telepathy is a framework for writing applications that can use real-time communication and collaboration features. In Telepathy, there are the so-called connection managers that connect to IM and similar networks and the clients that use those connections over D-Bus. This allows dividing the several tasks of an IM client to several applications, which makes it easier to reuse code and easier for applications to add collaboration features without caring about protocols, contact lists, presence status and all that stuff.

In Telepathy-KDE what we are trying to do is to integrate Telepathy with the KDE Plasma desktop. What we imagine is not to have a monolithic IM client like kopete or empathy but to integrate all the features of an IM client directly into the desktop. For this reason, we are going to add the following components into the KDE SC:

  1. A presence plasmoid. This will be a plasmoid sitting in your notification area or somewhere else, showing your online status and allowing you with a popup to change status, to enter a status message, etc…
  2. A contact list application. This will be a standalone application that will just show the contact list. It will of course have all the necessary actions to start a chat or a call or do something else with any of your contacts.
  3. A chat window application. This will be a standalone application providing just the chat window. When a new chat starts, it will be auto-launched via D-Bus service activation and allow you to chat.
  4. A VoIP call window application. This will again be a standalone application providing the call window, also auto-launched to handle calls. This is actually KCall, what I wrote in last year’s summer of code, but it won’t have the contact list and won’t be named “KCall”.
  5. An approver daemon. This will be a daemon sitting in the background and listening for incoming channels. When somebody requests that you start doing something with him (be it chat, video call, play a game together, share your desktop, etc…), it will show a KNotify popup allowing you to accept or reject the request.
  6. A file transfer daemon. This will be a daemon that will be auto-launched like the chat and call windows when you want to do a file transfer to or from one of your contacts and handle that file transfer for you.
  7. The nepomuk integration daemon. This is an implementation detail, really internal, not shown to the users. This will allow you to have metacontacts by pushing all of your contacts into the nepomuk database and defining relations between them. It will also allow at some point sharing contacts with akonadi and other cool stuff.

In the future, other components could be added, such as a logger daemon that logs all your chats into files or into a database or something like that and of course it will be very simple to add collaboration features to other applications for doing anything with your contacts. For example, krdc already has telepathy integration and it is possible that if someone requests you over telepathy to share his desktop, you could use krdc to view his desktop, without caring about firewalls or anything. Unfortunately, the server side of this is currently only implemented in gnome, so only a user using gnome can currently share his desktop with you, but that will be fixed in the future.

As a sidenote here, telepathy also allows you to share D-Bus connections over the IM network, which makes it extremely easy to add collaboration features to an application that has no idea about networks or protocols. With this feature, called D-Bus tubes, all you have to do in your application is to expose a D-Bus interface which will be called from the remote side using normal D-Bus calls, as if the other side was running on the same computer. With this feature, we could add collaboration features to many KDE applications in the future very easily. Unfortunately, this currently requires a patch in Qt that has not been merged yet and it is not yet certain if it will make it for Qt 4.8 (which actually screws the whole feature, but we can still hope it will be in Qt 4.8, so that we can start using it in KDE 4.7 or 4.8).

To get to kopete now, as you realize, there is no much place for kopete in all this. So, as soon as we merge all this in the KDE SC, kopete is going to get out of there. All in all, it has not received much development in the last years and even many of its former maintainers are now looking towards Telepathy-KDE, so I don’ t think we have any reason to keep it around. In addition, kopete’s code is not very much reusable in its current form, so we are not going to use it at all. Many people have stated that this may be a bad idea, but we have actually tried to port code from kopete and it didn’t really work, so we decided to do a new implementation from scratch.

I hope that pretty much explains everything now. Let’s stop talking about kopete and let’s start working on Telepathy-KDE😀

PS: If you want to get involved with it, come and find us on irc in #kde-telepathy on irc.freenode.net.

This weekend I participated in the Telepathy-KDE sprint at Collabora‘s offices in Cambridge. We gathered here to settle things down, make some design decisions, make future plans and start hacking on them. In overall, I think this was quite successful. We now all have a clear plan of what to do and what to aim for in the first release.

Things we did include:

  • We all together discussed the release roadmap. The first release is expected to be around when KDE SC 4.6 will be released, but not as part of KDE SC, since that would require us to merge stuff before the hard feature freeze which is too close and we don’t think we can make it.
  • We all together discussed about the components that we have, what problems each one has, what needs to be done, what are the blocker issues, etc and assigned jobs to everyone.
  • Olli gave talks about telepathy-qt4 and the suggested git workflow that we are going to follow as soon as we migrate to git, which will happen as soon as the KDE admins allow us.
  • Dario, Olli and Andre together hacked on and reviewed the telepathy-qt4 cmake branch, which seems to be in quite a good shape now for upstream inclusion.
  • Olli, Daniele and me discussed about code from our projects that could be upstreamed in telepathy-qt4 and in fact Olli did collect some nice ideas from us.
  • George and Sebastian looked at some nepomuk stuff that needed fixing and fixed them (it’s just nepomuk stuff for me, I have no idea what’s going on on that level yet :P).
  • Andre, Sebastian, Will, Dario and David did some UI mockups on the whiteboard that looked pretty cool. Andre later even did a quick QML mockup of the contact list.
  • Olli, George and me, with some input from Simon McVittie today discussed about how the approver (the thing that pops up asking you if you want to accept or reject a chat or a call or something similar) should be and behave. We will probably have to do some telepathy specification additions for this one, but it’s good that we finally came to a sensible conclusion on a problem that has actually been troubling some of us for a long time.
  • Dominik and David hacked on the chat window, doing some cool things like adding support for loading Adium themes.
  • Lots of other cool stuff, including eating a lot of pizza and burgers, drinking a lot of beer, socializing with the Collabora people, etc…😛

I think that’s all I had to say for now, stay tuned for more news about Telepathy-KDE:)

PS: We also have a group photo that can be found here, taken by Sjoerd Simons with Daniele’s camera:)


Get every new post delivered to your Inbox.