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)

6 thoughts on “GSoC week #2

  1. Looking forward to awesome audio/video applications in linux/kde, because atm it’s a joke, year of the linux my ass to say so.

    Keep up the good work!

  2. Mm..I have some questions about telepathy integration in KDE.
    First: what’s the status of Decibel? It seems it hasn’t seen any development since 1 year in kdesupport/decibel. Why?
    Second: you said that you’re using mission-control as account manager. Why not decibel? Are mission-control and decibel using the same dbus interface and thus interchangeable?

    Have a good summer of code!
    ..and tell your mentor to blog more often!!

    1. Decibel is kind of abandoned, as the whole framework is now working differently than in the original design. However, we are working on an account manager for kde, with kwallet integration, which will be able to replace mission-control in kde. As you said, mission-control and the kde account manager are using the same dbus interface and thus they are completely interchangeable. In fact, every component of telepathy is interchangeable, as long as it follows closely the telepathy dbus specification, which defines the basic dbus api for these components. I am not using the kde account manager yet, though, because it is not ready to use.

      PS: my mentor is also a student and he is having exams atm, so I guess he has no time to blog πŸ™‚

    2. Lol, Yeah, sorry I haven’t written for a while – exams and all that… but I promise I’ll start blogging (and coding full-time) again in 4 days.

      But for now, here’s a little update on what to expect soon:
      There’s going to be some exciting news before the end of the month as I’ll be working on Telepathy integration at the upcoming Nepomuk sprint.

Leave a reply to gkiagia Cancel reply