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 email@example.com 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 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