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