Latest Entries »

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/” probably means that the library “/usr/lib/” 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.:)

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:// 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.

This week I implemented complete webcam support in kcall. Both video input and output are working😀 Screenshot:

Screenshot of kcall in an audio/video session

Screenshot of kcall in an audio/video session

On the left side you can see the incoming video from the remote end, which in this case is my laptop, capturing myself through its webcam, and on the right side you can see the video that is being sent to the other end. Here, because I don’t have a webcam on my desktop computer as well, I am using gstreamer’s “videotestsrc” element as a video input, just for testing. Also, on the bottom right you can see the video controls for the video input (which is shown above them). For some reason, the video coming from my laptop has wrong colors there (my shirt is actually blue!), but that seems to be a bug in empathy (which is used as the remote client there). The preview in empathy also shows wrong colors, so…😉

Currently audio/video calls are working only with empathy or kcall on the remote side, using the jabber protocol. I also tried to test it with google’s web client (through windows/ie/gmail), but it doesn’t work. This is probably some bug in one of the underlying subsystems (in telepathy-gabble perhaps), but I don’t really care about it at the moment. There are still bugs, though. Sometimes I experience weird deadlocks in gstreamer threads and also sometimes the video stream is not sent correctly and the other side doesn’t receive anything. Some other times it works fine, though, which makes it really difficult to debug… I’m trying to debug those today, but with this extreme heat here in Crete, it is really difficult to work (today temperature reaches 41°C !!!).

Ok, I think I’ll give up for today and go to the beach…😀

This week I wrote some exciting (for me) code. Last weekend, while playing with gstreamer, I had this crazy idea to write gstreamer bindings for Qt. So, I started writing it for fun, outside the scope of kcall. It took me about one day to write something usable and I was really excited. Then, I remembered that some days ago, bradh in irc had told me that it would be possible to use solid to autodetect audio/video devices for gstreamer. Being excited with the bindings, I thought about making one library with the 1-1 gstreamer-Qt bindings and one extra library with extra stuff, like device autodetection using solid. So, I started writing this new library as well. I developed those two libraries for about 4 days and I reached a point where they were usable for the purposes of kcall. So, I merged them in kcall and rewrote the part of kcall that handles audio/video streaming to use them. At that point, I also wrote a small telepathy-farsight Qt wrapper (libqtpfarsight), mostly to provide a sane API for it (as the original telepathy-farsight API is really bad) and not to get rid of GObject stuff, but eventually I achieved both. So, now the core kcall code uses only Qt, the GObject ugliness is hidden in the libQtGstreamer and the libqtpfarsight libraries and I have device autodetection using solid😀 I think that was worth the effort, although it doesn’t offer any significant functionality to kcall.

And to add to my excitement, there was already interest for my bindings by one guy who is writing a plasmoid that uses a webcam to take photos. He couldn’t use phonon because phonon has no support for video input (yet?), so he started writing it with gstreamer and so he was interested about my work, which he already has started to use. I’m really happy to see my work becoming useful for others:)

Today I spent my day doing debugging, trying to understand why kcall does not receive correctly video from the remote end. I still haven’t reached the answer and I’m really disappointed because everything in the code and the gstreamer logs looks perfect.😦

Sending video is not implemented yet, but with the code as it is now, it is a matter of about 10-20 lines of code to add support for it. I will definitely do this in the following days, possibly tomorrow. I am also going to write a KCM for configuring device preferences, which is mostly done, as the library I mentioned above with the extra stuff that sit on top of QtGstreamer, already has a DeviceChooser widget, which can be used for selecting devices and has also support for saving and loading the selected device using KConfig😀 Next weekend this will hopefully be over, and I hope I will also have solved the strange bug regarding receiving video.

The only thing that makes me sad now is that this week of coding essentially sent to the trash the code I wrote two weeks ago, which took me some time to write, but at least I know it was self-educating.

Update on kcall status

So, time to let you know what’s the progress I’ve done in kcall. Unfortunately, nothing exciting has happened the past 2 weeks. I’ve spent about 1.5 week working on gstreamer device configuration. I spent lots of time reading documentation and code from empathy and phonon to understand how it all works, and also spent lots of time designing the code…

I chose a complex design, and I’ll explain you what I mean. Gstreamer provides elements that can be connected with each other to create a pipeline where data streams can flow from one element to the other. Each element is designed to do a specific job. For example, one element may provide audio input, another may apply a filter to the audio that comes from the input, another may encode the audio to vorbis, another may take audio input and provide a video visualization in the output, etc… For audio input and output, gstreamer provides several elements, mostly to support all possible backends (alsa, oss, jack, pulse, quicktime on mac, directshow on windows, etc…). The complexity starts exactly here. I needed a system where a user can configure which backend he wants to use and additionally set properties for this backend. For example, one may want to configure an audio output device. For audio output, gstreamer provides “alsasink”, “osssink”, “jackaudiosink” and many more. I needed a widget that can have a list with all those elements (listed with their proper names of course, i.e “Alsa”, “OSS”, “Jack”) and then allow the user to configure each element’s properties. For example, “alsasink” has a “device” property, where you can set the alsa device name where the output should go. If I chose to hardcode every element and property and create static dialogs in designer, the code would not be very flexible and portable. So, I chose to hardcode as little information as possible and create the dialog dynamically, based on a list of all the possible elements and their properties and by doing some gobject introspection to learn about the types of the properties, their possible values (if the element supports probing for possible values), their default values, etc… The code ended up being very complex and I haven’t committed most of it yet, it’s waiting in a local git-svn branch.

That was the main idea. As a side effect, I also wrote some code to auto-detect which element to use or load the preferred element from a KConfig entry and also load its properties from KConfig. Of course, reading settings is designed to work in cooperation with the configuration dialog, which will save settings. The auto-detection is a copy-paste from the phonon gstreamer backend. It’s not perfect, but it has a nice logic that should work for 99.9% of the users. The tricky thing about this autodetection is that it works better for gnome users, as in gnome there are the “gconfaudiosrc” and “gconfaudiosink” gstreamer elements that internally load the correct element and device based on gnome settings, and these elements also support application categories like phonon does (i.e. audio player, chat, notification, etc…). I wish we had such elements for kde as well… Actually I wish gstreamer was truly cross-desktop and cross-platform, so that it would be easier for me to use, without having to invent all this trickery and without feeling guilty of using gnome stuff. Gstreamer is a really cool framework in my opinion, so it’s a shame being tied up so closely to gnome.😦

Anyway, this work left me a bit behind I think. So, I am leaving it to work on more important stuff. Today, I worked on the call window UI. What I have now is this:

Current call window UI

Current call window UI

The participants dock is not shown by default, as it’s not very useful on two-person calls, but I added it because in the future kcall will probably support conferences between many people. From the tabs, the dialpad is also implemented and supposed to work, but it’s not enabled there because I am doing a call over jabber/jingle, which doesn’t support it (and doesn’t need it of course).

From tomorrow I plan to experiment with video support. I plan to have a small widget above those tabs for showing my local camera and a big one on the left for showing the other person, in two-person calls. For multi-person calls I will probably use separate windows for each participant, but I am not yet sure about it. Ideas and suggestions are always welcome.:)

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 over SIP yesterday to use its handy echo-test service, but it seems that telepathy-sofiasip has trouble connecting to

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

GSoC week #1

So, GSoC has officially started:) A week has passed already and I have started hacking on my project, kcall. Here is the result of the first week in an image:

KCall screenshot

KCall screenshot

This is a screenshot of what I have coded so far. It presents a contact list in a tree view. The first level of the tree shows the available accounts (here, “gkiagia” refers to my jabber account) and the second level shows the contacts of this account. I also wanted to have one more level for the contact groups, but I haven’t found yet how to get the contact groups using the TelepathyQt4 library. Right clicking the items in that list brings a popup menu with options. For account items, it allows you to set the account status (online, offline, away, etc…) and for contacts, it allows you to call them. The call function is not yet working, though. I expect to spend my next week implementing this functionality.

This is just a draft implementation of the contact list and I don’t expect it to be the same in the final version. There are a couple of things that are still troubling me about it, so I decided to leave it as it is for now, which is usable enough for me, and proceed with implementing making and receiving audio/video calls, which is the most interesting part of the project. Later, I can come back and polish the contact list and the rest of the GUI. (To tell the truth, I don’t like designing GUI’s, so this week I just did the very basics to make it usable for me so that I can forget about it for now and start working on real stuff!)

The implementation was rather easy. Telepathy provides all the stuff I need, so essentially the code does the following: It connects through dbus to the telepathy account manager (I am using mission-control 5 from git as an account manager), it gets the list of available accounts and adds them in the first level of the tree model. For each account then, if the account is connected, it fetches its contacts and adds them in the second level, or else it connects to a signal that notifies it when the account gets online and fetches the contacts when this signal is emitted. In addition, it connects to a couple of other signals to track changes in accounts and contacts, so that it updates the tree when there is some change. The interesting part was implementing the tree. The implementation consists of an abstract “tree model”, which inherits QAbstractItemModel and implements the necessary functions to export a tree, a couple of “tree item” classes, that represent items in that tree, a controller class, which exports actions on the items and handles the popup context menu internally, and an unmodified QTreeView for visualizing the model.

Some of you may wonder now, how does telepathy work? It is rather simple. Different parts of an IM/VoIP client are split into various processes. There are the connection managers, that implement the various protocols (jabber, sip, msn, whatever…), a central account manager that stores all the accounts and the various GUI frontends (there is also the channel dispatcher, but I still haven’t made use of that in kcall and I don’t feel confident talking about how it works, as I don’t really know yet). All of them speak to each other over dbus, so to get information about an account or a contact (like what I did this week) is just a matter of talking to the other processes over dbus and getting the information. This is really cool, because it allows us programmers to reuse code from other projects. For instance, I didn’t write any protocol-specific code for kcall, and this very simple contact list that I wrote can work with *any* protocol for which there is a telepathy connection manager available:) The code was tested with the “gabble” connection manager, which exports the jabber protocol, but I could have used anything else…

So, that’s all I have for now about kcall… I will blog again next week with my progress on making calls:)
Stay tuned…

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😀 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.