The GNOME Women edition of GNOME Journal has been released, including an article by yours truly on Telepathy and MC5. Check it out.
Month: November 2009
Why Telepathy is not like libpurple
It seems, even though we talk about Telepathy a lot, that there are still people out there who believe that Telepathy is really just a reimplementation of libpurple, just with an annoyingly retentive specification, and D-Bus.
The big thing to understand about Telepathy is not that it's platform independent (even though it is, and that's pretty neat). Or that it's modular (even though it is, and that's also pretty neat). The neat thing about Telepathy is that it's a service. Telepathy provides communications as a service.
What does this mean? This means that Telepathy is not just a library for enabling communications in Empathy, or Kopete. Telepathy can enable communications in everything. Any program can listen to and interact with Telepathy. This means that you can send a user files, straight from Nautilus; or share your desktop with Vinagre/Vino, via a Telepathy Tube; all without having to set up your accounts in each of these programs (this information is stored in the Account Manager, a session-wide Telepathy service responsible for maintaining accounts and connections — Empathy's accounts dialog is just a user interface to this service) or needing to establish a connection per application.
Because the information you need is available everywhere, this allows communications features to be integrated into places where they make the most sense in your desktop, rather than implemented in your contact roster (like another chat client does). For instance, mail notifications that Telepathy learns about from webmail services such as MSN and Yahoo (note: not yet implemented) could be plugged into the existing mail-notification applet, or into Evolution to hint when to pull from IMAP. GNOME Shell could provide an embedded GMail-like chat-UI, with popout chat-windows provided by Empathy. All of this is possible without those applications having to have their own preferences dialog for your accounts.
telepathy-glib provides classes for talking to the the Account Manager and Channel Dispatcher, setting up channels and handling contacts. In the future this will be expanded to make it much easier to develop Tube clients and other common tasks (note: avoid libtelepathy and libmission-control, they are deprecated traps and not to be used). Hopefully soon there will be a telepathy-gtk to provide common, reusable GTK+ widgets that applications can use. Telepathy-Qt4 has made it's first shared-library pre-release for those who prefer the other toolkit. If you're interested, I've been working on the Telepathy Developer's Manual.
Useful python trick of the day: dict.get()
How often in Python have you written something like:
d[k] if k in d else "Default"
Admittedly this has gotten a lot shorter since the inclusion of ternary operators in Python, but did you know that Python provides a get method for dictionaries that allows you to provide a default?
d.get(k, "Default")
I only found out today when reviewing code. Exciting!
status update on Clutter-GTK
Some time ago I wrote about my work on Clutter-GTK. Well, I finally got around to rebasing this branch so it could be merged and ebassi merged it for me last night.
There are still bugs in the code that I've not fixed, but many eyes make all bugs shallow, right?
The code includes a number of examples of how to do things.
If you're going to use these classes, you should understand how they work. There are caveats. Certainly I wouldn't base your entire toolkit around the interchanged use of GtkClutterActor and GtkClutterStandin.
GtkClutterActor takes a GtkWidget, rendered offscreen to an XPixmap, and paints it onto a GL texture which it draws on the Clutter stage. As a result, it can draw that texture anywhere, at any stacking level, and do things like taking events and sending them back to GTK+. Updating of the offscreen pixmap is done using Damage events, and things are generally peachy.
Things basically work like you expect. Although there are some performance issues where widgets that draw using two expose events will sometimes have a delay between the two Damage events that I've not yet explained, which can cause a visual rip.
If GtkClutterActor lets you embed a GtkWidget into a Clutter stage, then GtkClutterStandin goes the other way around, allowing a ClutterActor to be placed within a GtkContainer; but the implementation is different. The ClutterActor is not rendered into offscreen memory, and then copied into an XPixmap and blitted into GTK+, this would not allow for all of those exciting animations you want to do.
Instead what happens is that GtkClutterStandin reserves space within a GtkContainer for the actor it proxies and then places that actor on top of the texture containing the widget contents.
Bugs should be filed in the Opened Hand Bugzilla.
bump
So, I quite like the idea of Bump, a technology that enables data transfer by matching a bump read by your phone's motion sensors along with information like your GPS location. However, it does require sending all of your contact information to a 3rd party server, maybe that's fine? Maybe it's not.
It seems like this is exactly the sort of thing you could achieve using telepathy-salut (link-local XMPP) and Telepathy Tubes. You would have a MUC (multi-user, many-to-many) D-Bus tube where people's devices announced bumps, when clients found a match. Clients could then open up a 1-to-1 tube to transfer their data. Matching it slightly easier, because you'd only have to look at bumps on your MUC (plus you have the bump sensor reading + GPS)
Unfortunately this idea does full down with one problem. Multicast (as used in link-local XMPP) requires you to be on the same network segment, which it not something that can always been ensured, especially for phones and especially if there is no wireless network around. If the radios were also joined to an ad-hoc network for finding people nearby, this could work. Some wireless chipsets can multiplex their radios onto several networks, but you probably wouldn't be able to do this portably across many devices.
decorator factory for dbus-python methods
This is a crazy idea I had; that I want to share with people.
When you're implementing an object in dbus-python, you decorate your published method calls like this:
class ExampleObserver(dbus.service.Object): ... @dbus.service.method(dbus_interface=telepathy.interfaces.CLIENT_OBSERVER, in_signature='ooa(oa{sv})oaoa{sv}', out_signature='') def ObserveChannels(self, account, connection, channels, dispatch_operation, requests_satisfied, observer_info): ...
The input and output signatures are incredibly easy to get wrong. The thing is, most D-Bus APIs (e.g. Telepathy) have a specification that contains these arguments. Some APIs (e.g. Telepathy-Python) provide generated code including interface names and constants. So why can't we do something more like?
class ExampleObserver(dbus.service.Object): ... @telepathy.decorators.Telepathy.Client.Observer.ObserveChannels def ObserveChannels(self, account, connection, channels, dispatch_operation, requests_satisfied, observer_info): ...
With a decorator factory that looks up the parameters and then wraps the dbus.service.method factory.
Well, I just wrote a proof-of-concept. It looks something like this:
class Decorators(object): methods = { 'org.freedesktop.DBus.Properties.GetAll': [ 's', 'a{sv}' ], 'org.freedesktop.DBus.Properties.Get': [ 'ss', 'v' ], 'org.freedesktop.Telepathy.Client.Observer.ObserveChannels': [ 'ooa(oa{sv})oaoa{sv}', '' ], } def __init__(self, namespace): self._namespace = namespace def __getattr__(self, key): return Decorators('%s.%s' % (self._namespace, key)) def __call__(self, func): iface = self._namespace.rsplit('.', 1)[0] in_sig, out_sig = self.methods[self._namespace] return dbus.service.method(dbus_interface=iface, in_signature=in_sig, out_signature=out_sig)(func) def __str__(self): return self._namespace decorators = Decorators('org.freedesktop')
Obviously in the real version, it would have a generated map of functions, or map of interfaces each with a map of functions, and a way to handle signals, but neat huh?
