It’s been a long time since I blogged, primarily because I was busy with college stuff and working on a couple of cool projects. Now that I have some spare time, I can talk about some of the stuff I’ve done over the past 7-8 months.
At the Desktop Summit last year, George K. from the Telepathy team introduced me to Robert McQueen (A huge thank you! to George K.). I expressed my desire to intern at Collabora and Robert suggested a couple of projects, and libnice (A NAT Traversal library) piqued my interest.
As part of my internship at Collabora I worked on implementing ‘Dribble Mode’ in libnice. Now, I had absolutely no idea about NAT Traversal and had never worked with GLib, which made all this even more exciting!
Without going into too much detail (I’ll do a whole blog post about NAT traversal), dribble mode primarily works by allowing libnice to recieve remote candidates (candidates can be thought of as IP addresses, but that’s oversimplifying the concept of a candidate) while gathering local candidates. Implementing this was pretty trivial, but reading the STUN and ICE RFC’s to understand how NAT traversal works and familiarizing myself with the codebase took most of the time. Kudos to Youness for patiently explaining me what goes where!
Working with data packets and watching STUN requests/responses whiz by in wireshark was awesome to say the least.
I also faced a couple of hurdles in the beginning because the GLib binaries I was using were too new and the API had changed (I was using version 2.32 while nice used the 2.31 API) . So, after ifdef’ing some tests and code inside libnice, I managed to compile it.
(A huge help with fixing some of the broken code was clang, it throws awesome and pretty compile errors)
As of today, I have an outstanding merge request for this feature. Youness seems to be really busy, but I’ll make sure that this feature lands in the next release of libnice.
But, what does this mean for the average user? The biggest advantage that dribble mode offers is that two peers can start streaming data as soon as they have a working candidate pair, no need to wait for the other end to finish gathering it’s candidates. This means the frontend can start transmitting data even more quickly than before.
Project Neon has now reached a point where we can simply lay back and watch Launchpad delivering KDE goodness from git to end users. Something that was requested recently was VM builds for Neon. We’re working on that, and while we have the infrastructure to distribute the images setup (automated scripts to build and deploy images using Amazon S3) , we’re still having some issues with getting the config files just right to make sure that KDE starts up directly on boot.
These VM images should be helpful for people who want to try out new feature X on the latest and greatest KDE version but have a different OS/distro. We hope users will be able to find new and innovative uses for the VM images😀.
SyncEvolution, KDE and Synq
This is something that I have not talked about for quite a while, primarily because it was a bit hard to set up and getting configs right was a bit of a problem in my UI. However, with the new SyncEvolution release (1.2.99), everything (with the exception of SyncML with Google Contacts) works as expected, from the command line. I’m going to do a tech preview of my UI for SyncEvolution at the WebAccounts BoF and release my code right before Akademy ends.
My UI currently only supports SyncML templates, since KDE already has good DAV Groupware support. ActiveSync support is something that I’m investigating at the moment.
Oh how I absolutely love the technology behind VoIP calls. Peer to Peer communication is something I’m very passionate about, which is why I’m going to actively write more features for KDE Telepathy Call UI. A couple of things that I implemented over the last couple of weeks are Echo Cancellation and respecting the user’s preferences of webcam’s in Phonon.
As of right now echo cancellation is only supported for pulse sources and sinks. You can get this feature from either ktp-call-ui master or the 0.4 branch where it has been backported.
The Call UI also respects the user’s preference of webcams if the user has multiple webcam’s. Preferences can be configured in the “Multimedia” module in “System Settings”.
I also have a working implementation of holding calls in one of my personal clones, but hasn’t been merged yet because I have yet to figure out a way to display error messages to the user if holding the call fails. One of the discussions that I want to have at the KDE Telepathy BoF is about the future of P2P VoIP in KDE.
I’m also going to implement App Indicator support for the text-ui, just need to talk to Aurélien Gâteau about the implementation details at Akademy😉.
Last, but not the least, I’m coming to Akademy! Thanks to the e.V. for sponsoring me this year, I’m mostly interested in attending BoF’s such as the KDE Telepathy BoF, the KDE Author’s BoF and the WebAccounts BoF. I’ll also attend the QML workshop by KDAB and pick up some QML skillz.