On Monday, GSoC is officially over, so I thought I should make a post describing what I accomplished, what I didn’t and what’s the current status of my project, KCall.

Currently, KCall supports quite well audio/video calls over Jabber/GTalk. The fact that it supports only jabber, though, is not my fault, but it’s the fact that no other connection manager apart from telepathy-gabble (the connection manager for jabber) supports that well doing calls. In fact, there are only two connection managers that support calls, as far as I know: telepathy-gabble (for jabber) and telepathy-sofiasip (for sip). Unfortunately sofiasip does not support certain features that are needed by KCall (yet), so although it may work, there are things that you can’t do, like for example calling other people, which is a crucial feature. So, with sofiasip you can only receive calls and sometimes even this doesn’t work as expected. Streams may not get connected, you may have only one-directional audio and things like that… Don’t ask me why, I have no idea.

If you try KCall, you may notice that the quality of the UI and the general behavior of the application is not as good as possible. There are two issues that prevented me from improving it further:

  1. KCall is a telepathy client that needs to comply with the StreamedMediaChannel specification. However, this specification is not well-defined and there are many problems with it. For many things to work, some assumptions that are not part of the specification have to be made and these assumptions make it extremely difficult to implement advanced features like multi-user conference. In fact I had to assume that the channel can only have 2 participants and implement hacks on top of this… Very ugly, but required. And these assumptions limit the behavior and functionality as well. The problem though lies in the specification, so other clients and connection managers also have the same problem. Empathy works in a similar way. If you take a close look, KCall resembles empathy a lot in functionality and behavior; this is the reason why. Hopefully, the specification will be fixed and I will rewrite parts of KCall to fix it and improve it.
  2. The contact list currently looks awful. The reason I did not improve it is that in the near future the way of managing the contact list in telepathy will change. It is planned to use nepomuk to store relations between contacts, so that we can have metacontacts like in kopete and possibly associate them with the kaddressbook contacts as well. So, if I try to improve the contact list now, it will just be wasted effort, since I will have to rewrite it anyway.

So, from my point of view, KCall is as good as it can be. Sorry that it can’t be better yet.

If you want to try KCall, you can check it out from svn (svn://anonsvn.kde.org/home/kde/trunk/playground/network/kcall) and follow the instructions in the README file that I wrote a few days ago. Note that it still has some important bugs and I don’t think it is ready for general purpose usage, however, I would like it to get some testing. Unfortunately, it has a lot of ugly dependencies.😦 Most of them can be found in packages, except perhaps telepathy-qt4 that is not a stable library yet. You can find it here (check the URL field there to get the git url). This is the master branch, which builds with autotools, but there is also a cmake branch in this repo (Just note that the cmake branch has to be built with -j1 and it may not be up-to-date always). I won’t go much into details, I expect you to know how to use git already:) Note that some distributions may be shipping a library called telepathy-qt, but note that this may be the (too) old telepathy-qt library from kdesupport, which is now completely rewritten.

PS: If you are a debian/ubuntu user familiar with debian packaging, you might be interested in this repo.

PS2: I may make an unofficial debian/ubuntu kcall package later this week… I’ll think about it…

PS3: I will write this, but don’t flame me… Just FYI: Storing passwords in the telepathy account manager is not safe, as the passwords are later exported on dbus. I would recommend you to use a dummy password for your jabber account, or even make a new testing account with a dummy password, or at least don’t use the same password for your root and/or regular system users and for your jabber account. And kill mission-control-5 when you don’t need it. Also note that the console log of kcall also prints the password in plain text somewhere… (telepathy-qt4 is to blame…). So, don’t put the log in pastebins without removing the password! I am going to email the right persons about this, as it is totally unacceptable imho. Just watch out until it is fixed.