Wednesday, May 5, 2010

Using telepathy-glib in python through gobject-introspection

Until now, you had two options for writing telepathy clients in python: use the low level D-Bus API through dbus-python, or using telepathy-python which provided very little more for clients apart from registering the zillion of constants in Telepathy.

Telepathy-glib is a library that provides a higher level API for interacting with the Telepathy framework than the low level D-Bus API. No languages bindings exist currently for this library so only C apps such as Empathy used it, developers using languages such as Python and JavaScript were stuck with the D-Bus API and generally each app invented a more or less complete new API on top of it.

In parallel to a push for adding more high-level APIs to telepathy-glib, we are looking at what remains to be done in the gobject-introspection stack so we don't need to write static bindings for each language. After some weeks hacking on Gjs (Danielle Madeley), Vala (Travis Reitter) and PyGI (me) things are starting to take shape.

Following Danni's post on her progress, here comes an example observer written in Python and using PyGI to call telepathy-glib:

import gobject
gobject.threads_init()

from gi.repository import TelepathyGLib

#TelepathyGLib.debug_set_flags('all')

def observe_channels(observer, account, connection, channels,
dispatch_op, requests, context, user_data):
print 'observe_channels'

print 'account = %s' % account.get_object_path()
print 'connection = %s' % connection.get_object_path()

for channel in channels:
print 'channel = %s' % channel.get_object_path()

if dispatch_op is not None:
print 'dispatch_op = %s' % dispatch_op.get_object_path()
else:
print 'dispatch_op = None'

if requests is not None:
for request in requests:
print 'request = %s' % request.get_object_path()

context.accept()

dbus = TelepathyGLib.DBusDaemon.dup()
observer = TelepathyGLib.SimpleObserver.new(dbus, True, 'PythonObserver', True,
observe_channels, None)
observer.add_observer_filter({
TelepathyGLib.PROP_CHANNEL_CHANNEL_TYPE: TelepathyGLib.IFACE_CHANNEL_TYPE_TEXT,
})

observer.register()

main_loop = gobject.MainLoop()
main_loop.run()


This needs the latest code in telepathy-glib, gobject-introspection and pygi, and also a patch to PyGI that hasn't been release yet.

Monday, April 19, 2010

The 2010 Python GNOME hackfest is done!

Everything has to come to an end, and though this week has been full of hacking fun and beer work, I will welcome some rest back at home. Follows a recount of the time here.

After arriving to Boston last Monday, dropped my stuff in J5's house and went together to have some beers with some Sugar SLOB's at the CBC, there I finally met Colin Walters, putting one more face to an IRC nick. Afterwards we went to the OLPC offices to discuss Sugar Labs' trademark policy, and though I had to leave shortly after because of the lack of sleep, turns out they swiftly solved this issue that has been dragging on for so long, congrats!

On Tuesday several of the Sugar SLOB's got together to discuss miscellanous stuff about Sugar, mainly doing some high-bandwidth chatter to share our positions on several issues. Discussions should follow soon on the IAEP mailing list.

Wednesday started the hackfest, met Zach Goldberg, John Ehresman (of Wingware fame) and Red Hat's David Malcolm. I'm still impressed by the professionalism and technical knowledge of these guys, it allowed us to keep a strong focus and to overcome together the roadblocks we found, even when we weren't able to agree on a single position. David partnered with John and J5 on the Python 3.x side, and Colin, Zach and me on the introspection side. Having in the same room people with as a deep knowledge of Python such as John and David also helped a lot to the introspection side of things.

From Thursday to Sunday we just continued hacking on our goals, from 9am to 6pm on the OLPC offices with a small pause to grab food. Was so much fun that we only stopped when our brains grinded to a halt. Check the links below from Zach for more details about each day.

On Saturday night we celebrated the first PyGI release: 0.5. One very important outcome of the hackfest is that Zach has joined the maintenance team of PyGI, assuring its continuity, this will mean that PyGI will have a well triaged list of bugs, patches will be reviewed on time and releases will be made on time. Simon van der Linden (who unfortunately couldn't make it to Boston) and me will be lending a hand on that from time to time.

The Python 3.x patches haven't landed yet because are very invasive and we need to make sure we don't introduce more regressions than what can be fixed timely, we don't want to break all PyGTK software out there! So the plan is to keep developing the Py3k ports of PyGObject and PyGI in separate branches and test them with big codebases such as Sugar until we are confident of their stability, then we'll propose the merge. Both ports are feature complete and ready to be tested, which is a giant step forward.

I'm very grateful to my employer Collabora for having sponsored the time I spent hacking on PyGObject (and traveling!), to the GNOME Foundation for sponsoring my trip, to my OLPC colleagues for lending us their facilities, to Red Hat for taking us out for dinner and to Canonical for the coffee. Also, my special admiration to Red Hat for understanding that a strong downstream requires a strong upstream and sending three of its best hackers to lend us a hand here.

You can read more about the hackfest from others:

* http://arstechnica.com/open-source/reviews/2010/04/python-support-in-gnome-gets-a-boost-from-hackfest.ars

* http://blog.verbum.org/2010/04/14/pygtk-performing-engine-maintenance-while-the-car-is-running/

* http://zachgoldberg.com/2010/04/15/gnomepython-hackfest-2010-day-2-or-how-to-actually-coordinate-packages/

* http://zachgoldberg.com/2010/04/17/pygi-hackfest-day-4-a-call-back-to-the-past/

* http://zachgoldberg.com/2010/04/18/pygi-version-0-5-the-watch-out-theres-a-volcano-release/

* http://www.j5live.com/2010/04/12/gnome-python-hackfest-thanks-to-sponsors/

* http://www.j5live.com/2010/04/14/caffeined-up-and-starting-to-hack/

* http://www.j5live.com/2010/04/14/gnome-python-hackfest-day-1/

* http://www.j5live.com/2010/04/15/gnome-python-hackfest-day-2-quick-roundup/

Wednesday, April 7, 2010

Python + GNOME hackfest is set

Everything is ready for the hackfest that will update Python as a great language with which to program in GNOME.

In case you want to hack with us but cannot be at Cambridge, the attendants are going to hang on the #pygobject #pygtk, #pygi and #introspection channels at GIMPNet. Just say hi and we'll find something cool on which to hack together.

Update: channel #pygobject doesn't exist, should have written #pygtk instead.

Friday, March 19, 2010

Sugar with better Telepathy

After three weeks of little coding but much reading, a reward:



This shows the Chat activity talking to Empathy through link-local xmpp. This was already possible, but the difference now is that Chat is a normal telepathy client, and it has been activated by dbus as would be any other telepathy-enable application in GNOME, Meego or whatever.

The current code is very sketchy, but we are starting to get a good sense of the next challenges. If you are interested in knowing why this is important, see my previous post.

Progress can be followed in this page.

Saturday, March 6, 2010

Update on the Python/GNOME hackfest

The hackfest is going to happen from 14th to 18th April in Boston (MA, USA). We haven't agreed yet on a venue, but we are aiming for something near Kendall Square.

We'll be 3 people working on Python 3 support, and 3 more on the introspection bindings. More details at http://live.gnome.org/Hackfests/Python2010.

The GNOME Foundation will be sponsoring the travel, an as-of-yet unnamed sponsor will be providing the venue and the GNOME Foundation board is busy looking for sponsors for hacking food and such.

Wednesday, March 3, 2010

Early childhood hackers

Of course, Sugar hasn't the monopoly in FOSS in primary classrooms, but are there other projects whose contributors include those children? Teacher L.M.Y.Lim is working to make that happen:
...
- I have to narrow my focus on the goals I have for the children. Objectives will include:
The children will generate a list of responsibilities a QA engineer, or “tester” has;
The children will generate a list of what makes a good QA engineer;
The children will write about their experience – not only about what they figured things out, but also how they did it.
The children will provide feedback for future SoaS deployment or pilots.
...


And Mel briefed about their first meeting with the community.

Tuesday, March 2, 2010

My focus during 0.90: Collaboration

From now on to the next Sugar release in about 6 months (0.90), I'm going to be working on improving the collaboration stack in Sugar, graciously sponsored by Collabora. Collabora employees developed almost all of the collaboration code in Sugar, and are the main force behind the Telepathy framework, on which Sugar's collaboration is based. Though pervasive collaboration is one of the major features of Sugar, it hasn't been funded for a long time and there's large room for improvement, also due to the new developments in Telepathy. My work will aim to make presence and collaboration more reliable and to put the pieces in place for enriching the experience with the new features in Telepathy.

Collabora has almost 5 years of experience in open source software so they know very well that for a project to survive, someone needs to take the role of software maintenance, and that's why they are going to be sponsoring me as well 1-2 days per week of maintenance work. Maintenance work includes tasks such as reviewing proposed changes, maintaining the bug database, participating in community discussions, welcoming new contributors, making new releases, etc, and is fundamental in keeping an open source project such as Sugar alive. That's why I would like to put a call for our many users of Sugar to help the other maintainers keep doing their work by supporting them financially. As of today the only Sugar maintainers that are paid anything for doing their job are Sayamindu and me, and this is not sustainable.

The grunt of the work will be dropping custom code that was developed ad-hoc in the early days and making Sugar use instead new developments in Telepathy. Many of the bugs we see today in collaboration are due to the several layers on which collaboration information is cached. By dropping the Presence Service and having activities call Telepathy directly, we'll improve the reliability of presence and collaboration.

There's also code in Telepathy that is exclusively for Sugar and that is redundant now due to new developments in other parts of Telepathy. I will be working as well in making Sugar don't need those specific mechanisms because the Telepathy maintainers will drop those pieces at some point and Sugar cannot be left behind. As well, Sugar depends on the server being configured in an specific way, breaking collaboration with non-Sugar specific servers, there will be work as well to remove this limitation.

By using the same pieces as other environments such as GNOME and MeeGo, Sugar will be closer to the development of those platforms and will be in a better position to take advantage from new features. We'll be reducing as well the effort required to maintain and further develop our collaboration stack, and we'll be sharing with others the burden of keeping our collaboration foundations solid.

Many of the changes will be under the hood and won't be seen nor by users nor by activity developers. Other changes will affect developers because API that they were using won't be there any more, I'm going of course to try to minimize this as much as possible. Other changes will impact the UI, mostly by adding new features, but sometimes will be changes required to make Sugar closer to the other Telepathy clients. I will be starting discussions very soon about all these changes so we can find the best solutions for each.

In summary, Sugar will improve in these ways:

- the collaboration code will be smaller and simpler,

- Sugar users will be able to collaborate through more networks, with more protocols, and with people not using Sugar,

- Sugar will be more compatible with future versions of Telepathy,

- we'll have a simpler path to acquire recent and upcoming features in Telepathy and related frameworks, such as VOIP and video calls.