Premise
I began working on
providing networking support to GNOME Games at the verge of GNOME 3.4 release. Now 3.6 release is around the corner and many people are happy about it. So am I, but more about the work I am doing and of which, sharing here with you, a glimpse. It began with a curious part of me which was left cliff-hanging and wanting to know more after a very live and exhilerating round of internship where I chose to work on Empathy- one of my favorite applications on the desktop!
I took the internships as a nudge for me to go ahead and try my luck diving into the huge pool of open-source developers I always wanted to be one of but was also a little scared of since there would have been no one to guide me or provide a walkthrough but after the internship, where I learnt equating page-turning software codes like page-turning a very interesting story-book which I always wanted to read, I understood what a blessing it was to have no one monitoring your moves! You hear of something interesting, you already know of something where you can apply this new interesting thing and VOILA! You have just created a new technology in your mind and you can create a brand new cool application based on it! All you have to do is to follow your instincts as you are totally FREE (as in freedom)!
First sight and a magnetic opportunity
So this very curious person, I, had witnessed a very powerful jumble of D-Bus and GIO - a
real-time communications service and framework named
Telepathy, during her internship (back in 2011) which was perhaps some opportunist's, quite creative and apt exploitation of pending plans of
DBusRemote with the added advantage of a hefty user base obtained from multiple presence and chat protocols it supports. I had no clue how I would make use of the new tool as I was glancing over this masterpiece, but I knew I wanted to know more of it!
Magically, roughly around that time, I was led to
Robert Ancell's
call for hackers to implement telepathy-networking for the GNOME-Games module he maintains. This required making use of telepathy's
dbus-tube channels which when established with the remote contact would provide me a DBusConnection to communicate the way I want to with an application on a remote computer which your remote friend is logged in with. This technology in itself was amazing (yes, D-Bus-Remote!) and it was an awesome chance for me to satisfy my craving to explore Telepathy and to give a closer look to GNOME's nervous-system (the D-Bus messaging bus) and try my hand at a few other GNOME's latest technologies which wouldn't harm and only be additional assets to my skills.
Besides the things I have blogged about earlier, I learnt how to create libraries and use
logging domains (which was very useful in debugging), write GSettings keys from multiple processes with dependency interactions in a controlled manner using delayed application,
generating vapi files using gobject-introspection[1], use DBus messaging bus and export objects on it using
GDBusConnection (in 3 different ways- low level method-calling and signal subscribing, higher level using Skeleton and Proxy objects, and the simplest of all, using Vala
dbus-attributes which I could leverage, Vala being the language in which
GlChess is mostly written and since I didn't want to create or manage another .vapi), creating
asynchronous operations, creating
GtkApplications from scratch and understanding their life-cycle, launching applications from code, making them handle command-line inputs in local and primary instances, parsing acceptable options using
GOptionContext, creating telepathy-channels and making a tube-offer.
I hAcKeD into
MissionControl (yay!!) - a daemon that is ALWAYS running on your favorite distribution with a well-known name of "
org.freedesktop.Telepathy.MissionControl5" on the session bus and is the primary sense organ of the telepathy system. (If you got scared at this, rest assured, I am an ethical hacker as you'll notice if you find this interesting enough to read further!)
I also found a few bugs in
telepathy-glib library, a
GObject-based C binding for the Telepathy D-Bus API (which interfaces
dbus-glib), which were generating a faulty
telepathy-glib.vapi and thus hindering the Vala implementation I was working over, and made my
debut commit (
bfo bug# 55024) to it.
Opportunities exploited
I had seen that Empathy recognizes when a contact of mine has
Vinagre installed on her system (and when I have
Vino) and shows me an option to initiate a remote desktop session with her. I was impressed by the ability to know someone's capabilities just on the basis of what softwares (s)he has installed. Ideally I wanted something like that for games too. One should not have to run GlChess 24x7 or have it loaded in memory in order to receive chess-playing requests from online friends.
To confirm my use case, I peeked into MC-5 (mission-control-5 daemon) and found that on startup, the daemon looks for all d-bus activatable services (the ones with .service files installed in XDG_DATA_DIRS/d-bus-1/services/) and then checks which ones of those are activatable telepathy clients (ones with .client file installed in XDG_DATA_DIRS/telepathy/clients/) and registers them as activatable telepathy clients for the session. The capabilities of a contact are updated on all connection-managers at every recognition/modification of available activatable clients when MC calls.
This was cool and this was the basis behind how empathy-call works on the GNOME desktop. If you have empathy-call (UI application for handling telepathy's call channels and also a d-bus-activatable service) installed, your friends can always make a call to you which you can accept/reject. empathy-call is executed at runtime when after approval of an incoming call channel, the channel dispatcher in MC-5 wants to dispatch the channel to the call handler.
One fine day, I decided to try to fall into a need to have the above design implemented in GlChess. I knew this design would take a little more time and research on my part but I also knew that if not now, it would be implemented never! So, I started gauging the faesibility of this design and then I noticed that the design was flawed and aesthetically such an implementation of empathy-call shouldn't exist because there was no way for the advertiser of empathy-call to control his display of calling capability to his remote friends. He could only stop this advertisement by uninstalling empathy-call - that was inherently wrong. But that shouldn't stop me from implementing it and depriving users of such a cool feature! There must be a way created to make advertisement of an installed activatable service capability, to it's contacts, controlled by the user..
(O-o-o Back in mind: YAY!! I'll have more food for talks!)
The Hack: A roadblock cleared: That's what we have been waiting for...
...and it turned out, having this implemented wasn't very difficult! I already knew about GSettings by then and that I could easily read the serialized settings from multiple applications simultaneously. "Maybe something like a setting should suffice...", I thought to myself. I took a few Telepathy beans, a little GSettings setting sause, and shook them into a blender to create a recipe described in
bfo bug# 53818. "
EUREKA!!!", I yelled, while filing this feature-bug and necessity gave birth to invention! I am glad it received a positive and affirmative response from Telepathy developers and support from Robert with which
GlChess is moving towards incorporating this highly sophesticated design approach to set an example and to begin a new trend for the next-generation desktop applications! It took me a registerful of notes to come uptil this level and atleast four charts to come out with this design. Developers will surely get smitten to this revolutionary design! Yeah, you are already allowed to think possibilities you can have with this!! Gnome-Shell doesn't implement it yet (it doesn't
_really_ need it since it is already always running and loaded in memory throughout a user-session and wouldn't gain much with this apart from a possibility of an "advertise-call-capability" setting for example, which is also cool), nor do Empathy or Vinagre, but they are most likely the candidates which will benefit from it. This work, as a part of my telepathy-networking support suite of branches, is planned to be merged to GlChess master in 3.7 which will give it a chance to be thoroughly tested before being delivered to a release and will also provide many other desktop applications which are telepathy clients (like Empathy, GNOME Shell or Vinagre) a chance to implement this
capability-advertisement-control concept, thereby finishing their implementations still-wanting attention (e.g.
bgo bug# 576376) and GNOME users will experience a complete goodie package!!
Minor detours:
If you give a look at the WIP branch (or if you have already done that), you'll see that majority of the work was completed while some or the other freezes were in place. It turns out working on an intersection of multiple technologies is very tough when everything is unstable. Some of huge roadblocks and performance attenuators in my work this cycle were when I couldn't run empathy or any other application using folks after upgrading to Precise Pangola, without causing GNOME-Shell to freeze. Cause turned out to be showing signs of
https://bugzilla.redhat.com/show_bug.cgi?id=760542, but on Ubuntu. I could work on Unity for a while but ultimately I had to test chat-handler launching for GNOME-Shell too and I was so badly suffering with it that I had made my mind to fix that bug (incase some of you saw me building shell out of my way and wondered what happened!). I had some folks messages in .
xsession-errors just before the freeze and I hoped to get to the root cause using those. I built folks master. I tried to build GNOME-Shell master but I couldn't (no wonder - Mutter already broke its API in master) but to my relief, it turned out in the end that I could actually run my application with GNOME Shell 3.5.2 and Folks 0.7.1. But this happiness was also not long-lasting! Folks was changing very rapidly and I had to keep up with it. Games required Vala 0.15.1 and Folks was left behind, incompatible. Then folks made use of libgee-0.8 but the GNOME-Shell version I was working on made use of libgee-0.6 (which is named as gee-1.0, confusingly).
I was unable to run the newer GNOME-Shell due to: "Requiring Shell, version none: Requiring namespace 'Gee' version '0.8', but '1.0' is already loaded"
And everytime I tried to run the system-provided Gnome-Shell, I got a folks message: "Failed to reach quiescence normally (0 backends and 1 persona stores still haven't reached quiescence). Forcing IndividualAggregator quiescence due to reaching the timeout.", whenever my gnome-shell froze.
In the end, none of the folks applications ran on any window-manager including Gnome-Shell, Unity, Metacity and Compiz. To my relief, things got into a stabler mode closer to the end of the cycle and work started flourishing again... but I won't regret the delay caused by external factors since this is the prize which everyone had to pay, not just me, and this gap turned out to be a blessing where I could brainstorm and resolve a graver problem with telepathy-clients and come up with a design which would have otherwise taken a few more GNOME-years to materialize.
P.S.: This was a conceptual post. You'll see more pictoral and diagrammatic posts in next blogging session. ;)
(
Update: Added subheadings: will make locating keypoints easier in this so lo...ong post.)
Footnotes
[1] Games use a vapi file for a common support library written in C which is manually maintained by hand. I made a
few additions to it but found manually editing of this file like a punishment so I generated the symbols myself and copied them to this handwritten vapi. The tool I used is secured
here which may act as a live vapi generation tutorial.
