Tag Archive: KDE

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… :P (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 :D

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… :P

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 :)

Multimedia sprint

Today is an exciting day. I’m currently at the Athens airport, waiting for my next flight to Munich and then to Geneva, with final destination being Randa, Switzerland, where the kde multimedia & edu sprint will take place the following days. I hope everything is going to be fine. I can’t wait to meet all the other kde people there :)

The reason I’m going to that meeting is that I wish to take part in the phonon/QtMultimedia discussions and also try to find some solution for KCall’s integration with the rest of kde, since it currently uses Gstreamer for some reasons that I won’t repeat again ;) I hope that all these discussions will have nice results.

Introducing cmake_install

Merry Christmas everyone,

Holidays have come and I’ve finally got some time to get back to KDE for as long as the holidays last. Today I started from updating my KDE-trunk installation and while building, I remembered about this handy cmake_install utility that I wrote a few months ago but never shared it with anybody, although I wanted to. So, I decided to blog about it.

You may now wonder what this is about. I’ll start from explaining the problem first. When you build kde from svn and install with a simple “make install” in your home directory, sometimes you face the problem that the obsolete files that were removed from svn and are no more installed stay in your installation directory forever, taking space, sometimes also causing trouble, and the only remedy is to wipe out the installation directory and install everything from scratch. When I first started building svn snapshots of kde, I had faced problems due to this (for example, problems with plasmoids not working because simply they were removed and thus the versions I had were linking against older and incompatible libplasma…), so I decided I had to do something about it. After some digging, I found that cmake lists all the installed files in a file called “install_manifest.txt” in the build directory, so I wrote a small program that finds the obsolete files by watching the differences in this file between two different installations.

You can find it here. Initially, I had written it as a shell script, but later I realized that the code had a serious bug and to fix it I needed some data structures (a set to be more specific), so I rewrote it in C++ using QtCore. As a side effect, rewriting it in Qt made it portable :)

How to use it

1) Get the file and compile it. A simple “g++ cmake_install.cpp -o cmake_install -lQtCore -I/path/to/qt/include" will do. Alternatively you can set up a qmake or cmake project file, but it’s not really worth it.
2) Put it somewhere in your $PATH. I use ~/kde/bin for this purpose, as it’s where all the kde trunk binaries get installed.
3) Adjust your scripts to call “cmake_install” instead of “make install”. If you use the scripts from techbase, then you can do this by editing the “cmakekde” function.

Note: As this program relies on the existance of “install_manifest.txt” in the current working directory, it should only be invoked from the root of the project’s build directory (for example in ~/kde/build/KDE/kdelibs, but not in ~/kde/build/KDE/kdelibs/kdeui). If you want to just install a subdir of a project, you can still use “make install”, if you know that there are no changes in installed files or you can clean up manually obsoleted files. Also note that the root of the project build dir is specified the first time that you build the project. For example, if you build the whole kdesupport once from the top level directory, the install_manifest.txt will be in the kdesupport build dir. However, if you build the projects in there separate (i.e step into phonon/, build, install, then step into akonadi/, etc..), each project will have its own install_manifest.txt, but then you can’t use my program to install the whole kdesupport from the root dir, you have to install the sub-projects separately.


Being a Qt program, this program is fully portable. I have used it successfully in linux, freebsd and windows without any issues*. For platforms that make is not called “make” you just need to set the environment variable MAKE to whatever your make utility is called. For example, on windows/mingw you have to call “MAKE=mingw32-make cmake_install”

* Well, windows vista and 7 have an issue if you have UAC enabled. Because the word “install” is in the executable’s name, windows thinks this is an installation executable and executes it with admin privileges in a separate terminal. To fix this, either turn off UAC, or rename cmake_install.exe to something else (for example, foo.exe will work :P).

This time I am not going to blog about KCall, but about DrKonqi. Dario Andres and I, the drkonqi maintainers, are thinking of adding some new features for KDE 4.4. As you already know, most distros out there ship stripped binary packages with their debug symbols put in separate packages. One of the features that we want to add in drkonqi for KDE 4.4 is to make it able to install the required debug packages when there are missing symbols in a crash report.

Our first idea for implementing this was to have a shell script installed somewhere, which by default will do nothing, and let distributions customize it to install the required packages. The input given to the script is the executable name and all the libraries that appear in the backtrace with missing debug symbols. For example, a backtrace line that reads like “#5 0xbf123456 in ?? from /usr/lib/libkdecore.so.5” probably means that the library “/usr/lib/libkdecore.so.5” is missing debug symbols, so that library path is passed as an argument to the script.

This is already implemented in trunk (it was very easy to do), but I now want to go further than that. Being a debian packager myself, I attempted to write an utility to do this for debian. I found an easy algorithm that takes as input all the filenames of the binaries that need debug symbols and outputs the names of the packages that need to be installed, using apt-file as a backend for searching package contents. While working on this, I came up with the idea to put this algorithm in a KJob, which eventually made me think of another possible implementation of this feature: Have a unified GUI in drkonqi that takes plugins; every distro will have its own plugin and each plugin will export a KJob that will do all the work (finding and installing packages), or alternatively, that KJob will only find the packages that need to be installed and then drkonqi will use packagekit to install them or display some message to tell the user what to install if packagekit is not available (which is the case for debian, btw).

This scenario would be better than the scenario with the script, because it will allow us to have a unified GUI in all distributions and will also reduce the work of the distributors, as they will have to write only one small plugin instead of a whole application to do all the work. I don’t know however if this scenario works for other distributions, as I don’t know how they handle debug packages.

So, dear fellow packagers and anybody else who has an opinion on this, I would like to know how your distribution handles debug packages and what is your opinion on all this, so that I can decide what to do and how to do it. :)

GSoC Week #4

I skipped a week without blogging, mostly because I was busy last weekend, but now I think it’s time to report my status on kcall again…

Last week I spent about 3 days studying gstreamer and I ended up creating a media handler class using telepathy-farsight and gstreamer, which is able to handle audio calls without problems. The only bug I have there is that the microphone volume control does not work correctly, but I hope I will solve this some time (it’s not urgent anyway). The code is heavily based on andrunko’s telepathy-qt4 media branch, a branch of the telepathy-qt4 library that includes a high level API for handling all this farsight/gstreamer stuff, but as this branch is not ready yet and as I will probably need more control over gstreamer than what this media API gives me, I just copied and adapted this code to work in kcall. The only part I don’t like about this gstreamer stuff is that its dependencies are HUGE. For example, I just need to depend on libxml2 and telepathy-glib because some of the headers I include, include in turn some headers from those libraries… Totally unacceptable imho. Actually, big part of my work here was to create correct cmake scripts that can find and use all those dependencies….

Ok, so after making the media handler, I split the part that handles calls in a separate executable, implementing the telepathy Client.Handler interface. I merged in this executable the kpart I had created, as after reading the telepathy spec about the channel dispatcher, I realized that there is no need to have a kpart. A separate handler process is enough to be reusable by any other program. If another program (for example, kopete) wants to start a media call, it can just request a media channel from the channel dispatcher, and the channel dispatcher will automatically open a handler for media channels, such as this kcall handler. Apart from that, I also created a system tray icon (using the new KNotificationItem API) and an approver class, which shows a popup message (using knotify) when there is an incoming call and allows the user to accept/reject the call.

This week I had an exam on Wednesday, which prevented me a bit from working on kcall. In the time that was left, I started working on improving the call window. I added a dock widget with volume controls and a timer showing call duration, and I also fixed some internal stuff to report correct status to the user and accept incoming calls correctly.

Next thing to do now is to improve the UI of the call window, so that I can also add the video widgets on there and play with video support. I will also need to find some software and protocol that will allow me to test video calls easily. I tried connecting to ekiga.net over SIP yesterday to use its handy 500@ekiga.net echo-test service, but it seems that telepathy-sofiasip has trouble connecting to ekiga.net.

Btw, if any of you out there would like to help me designing a good UI, I would love to hear some ideas and/or see mockups of how the call window UI should be, as I’m really bad at designing GUIs on my own :P The basic idea is that I need some widgets to see video in the middle, plus some list with the participants of the call, plus volume controls for mic & speakers, plus a dial pad… I’m currently thinking of putting all optional stuff (participants list, volume controls, dial pad) in dock widgets and put two video widgets in the middle (one for the remote contact and one for myself)… but now that I think it again, the problem here is that *theoretically* a call can have many participants, so just two video widgets may not be enough. And on the other hand, what should be displayed for audio-only calls? I think you get an image of the situation, so, I would love some ideas here :)

GSoC week #2

This week went a bit out of plan. I didn’t work much on kcall as I was busy with other things. On Tuesday I had two exams (fortunately, quite easy ones), which kept me busy for both Monday and Tuesday. Then from Wednesday I started packaging KDE 4.3 beta2 for debian, which was quite challenging and kept me busy for 3 days (Wednesday-Friday). I packaged only the basics (kdelibs, kdepimlibs, kdebase-runtime, kdebase-workspace and some kdesupport dependencies) and of course they are not of release quality yet (so don’t expect 4.3 beta2 packages in debian).

In the meanwhile, despite being busy with other stuff, I took some time to study a bit more the “call example” from the TelepathyQt4 examples, which is essentially a simple version of what I am developing, and I wrote some code for a “call window”, which is an object that in the future it will be able to handle a call and display a nice window with status info, the video widget, audio/video controls, etc… Yesterday (Saturday), I polished a bit the API of this object and I implemented some really basic functionality. While I was looking at the code, I thought it may be better to develop this window as a kpart, which will make it possible to be reused later in other projects, like kopete for example (when it is ported to telepathy, if this ever happens). So, late yesterday afternoon, I ported this window to use kparts. However a linker issue (telepathy bug 21340) stopped me from finishing it. Today I managed to fix this issue and I am now working on finishing the kpart. Unfortunately I don’t have much time to work on it today, but I promise it will be ready by late night today or tomorrow morning.

Now, the next step is to implement an object that will do the encoding/decoding of the audio/video. As an exception to the general design of telepathy, audio/video handling is specified to be done by the application itself and not from the connection manager that connects to the protocol. To handle this, telepathy developers have designed a library called telepathy-farsight, which internally communicates with the connection manager and handles the audio/video streaming part. To do the actual encoding/decoding, gstreamer must be used. Gstreamer is a library that resembles phonon a lot. It uses a similar pipelined architecture. From what I understand, telepathy-farsight provides a gstreamer source and a sink, which can be connected to other gstreamer objects that will do encoding/decoding, grab source from the mic or camera, output to alsa and some video widget, etc… Unfortunately, farsight and gstreamer are the only way to go here. This is how the telepathy specification is designed, and while I bet it would be possible to write something similar to farsight that will do the same job using Qt and phonon, this is too much work to do and if this ever happens, that will take a few years. So, I will have to spend this week learning the glib/gobject and gstreamer basics, so that I will be able to write this part of kcall. The “call example” I mentioned earlier provides a sample implementation of this object, but although I could just copy it, I need to understand what it does so that I will be able to extend it.

I hope this week I will work more and I will manage to make a simple call :) My current plan is to have audio/video fully working (with controls and options) before July 6th (the middle of the gsoc period), so that I can spend the rest of the period doing UI/usability improvements and implementing secondary features that may be needed. (Notice: The author of this post has the authority to change this plan without previous notice! :P)

Hello planet!

Hello planet KDE!

This is my first post on planet kde, so I’ll first introduce myself. My name is George Kiagiadakis (gkiagia on irc) and I am a 20-year-old student from Greece. I was born and live in Iraklio, on the island of Crete and I study computer science at the Computer Science Department of the University of Crete. Some of you may already know me as I have been involved in KDE for a few months now. I first started my involvement from the KDE Bugsquad, doing bug triaging, and then I started fixing some bugs as well. I got an svn account in October and I first fixed some issues with kwrited (a daemon that sits in the background and listens for messages sent with write(1) or wall(1) on the same computer). During the period of the KDE 4.2 pre-releases, I also joined the Debian Qt/KDE Maintainers to help them with packaging, which I still do. Later, I started helping Darío Andrés with the development of a new version of drkonqi, the KDE crash handler, which will probably appear in KDE 4.3.

Being a student, I have now entered GSoC. At first I wasn’t sure if I should apply at all, and I probably wouldn’t have done it if it was not grundleborg to encourage and help me (many thanks for that, George). To my surprise, my proposal was accepted :D So, this summer I will be working on reviving KCall and creating a usable VoIP client for KDE, using telepathy. You can have a look at the complete proposal here. I like this idea, because currently there is no voip software available for KDE and also there is no KDE software available to the users that makes use of the telepathy framework, so I’ll be doing something really useful. Hopefully, at the end of the GSoC period, KCall will be ready to use to make calls to your friends! Well, I don’t expect it to be perfect, but it should work… ;)

I will keep you informed of my progress through this blog (or at least, I’ll try to do so)… Stay tuned! ;)


Get every new post delivered to your Inbox.