g_variant_equal() and dictionaries

For anyone using g_variant_equal() with a type containing a dictionary, you should the aware that, somewhat unexpectedly in my opinion, g_variant_equal() only returns true if (and only if) the keys in the dictionary are in the same order (GVariant implements dictionaries as an array of key-value pairs).

You can resolve this by using a function that recursively checks for semantic equivalence (such as this one).

I’m sure I’m not going to be the only person to find this useful. I’ve filed this as bug #622590.

introspecting tp-glib and converting DBus-GLib GValues to GVariants

Telepathy is a modular framework. At the very heart of Telepathy there is a specification that describes how the various connection managers, clients and other components interact with each other. The specification is written in terms of a set of D-Bus APIs.

Telepathy takes full advantage of what’s provided by D-Bus, which is why you see so many different interfaces in the specification (one day I’ll write more about this), but one thing it makes frequent use of is variant types and specifically string->variant maps (known in D-Bus parlance as a{sv} maps).

a{sv} maps are used by the DBus.Properties.GetAll() method, to return all of the properties in an interface (which are all of different types), but in Telepathy they’re used more generically with namespaced properties to make requests for communication channels and collate information. The types are specified by the key names.

Telepathy-GLib exposes these maps as GHashTables of element type string->GValue, which actually works quite well in C. Telepathy-GLib registers specific GTypes with GLib via DBus-GLib and we have generic utility functions to unpack the GValues into native C types. For simple types, this also works really well in the bindings. For simple types (int, string, boolean, etc.) GJS converts the GValue values in our map into native JS values and things are pretty neat. Unfortunately this does not work for complex, container types (e.g. sa{sv}as); GLib doesn’t provide enough API to query the complete type information of the GValue’s contents, thus it’s not possible to introspect.

The GLib solution to this problem is GVariant, a way to store values that keeps all of the type information in an easily accessible way. If tp-glib exposed a{sv} maps as string->GVariant, we would easily be able to unpack the complete type in GJS or PyGI. GDBus uses GVariant for passing around types, but porting tp-glib to GDBus would take a lot of effort and radically break the API and ABI, so just isn’t feasible at this stage.

But there is a solution! Unsurprisingly, DBus-GLib has the information to recursively unpack a GValue registered with itself, it requires this in order to marshal those GValues into a D-Bus message, but it also exposes this API so we can use it for our own ends. Thus it becomes possible to convert these GValues to GVariants! In fact here is some sample code (Telepathy-GLib is not strictly required, it’s only being used here to provide test cases). I’m hoping this utility can be provided as part of DBus-GLib and then used to provide alternative API for tp-glib that can be exposed to the bindings.

To complete the circle, I wrote GVariant unpacking for GJS, but it needs reworking to only unpack when explicitly requested instead of implicitly always.

Update: bug #28715 provides a proposed patch to dbus-glib.

Empathy master ported to GSettings

GLib 2.25.9 just came out, which included a GSettings bugfix I needed, so I’ve just merged the GSettings port branch I wrote for Empathy into master. Unfortunately this does not come with a fancy screenshot. It uses the DConf backend by default, if you do not have DConf, your settings won’t be preserved between instances.

This work includes a .convert file that can be used by gsettings-data-convert to convert from GConf to DConf. I got kinda bored of maintaining this file by hand, so I wrote an XSL script to generate it from the schema XML.

Bugs in GNOME Bugzilla please :)

Also, to the Americans and Canadians who enjoy Australian, female folk singers: my favourite band is touring your countries for the next three months (you have to click Next on the page to see every gig). You should go and see them!

Muji: multi-user Jingle

So there were two things I find exciting that got merged in gabble 0.9.12 (gabble is Telepathy’s XMPP/Jabber connection manager). First was support for SASL authentication channels, allowing you handle SASL auth mechanisms from a custom handler (e.g. by not supplying a password to Gabble, or a custom mechanism such as X-GOOGLE-TOKEN or X-FACEBOOK-PLATFORM); thanks to Eitan. Second was multi-user Jingle calls; thanks to Sjoerd.

Muji Demo Client
Muji Demo Client

This is all done as an extension XMPP/Jingle using a XMPP multi-user-chat room (the XEP). The work has not been integrated into Empathy yet, but there is a demo client (yes, it even works from Australia). Sjoerd writes more about it on his new blog.

Meego 1.0 on the Dell Inspiron Mini 1012

While on the topic of Meego, just a quick note for those looking to install on the Dell Inspiron Mini 1012.

Meego itself generally runs quite well on this device, but this machine has a Broadcom BCM4212 wireless chipset (also known as a Dell Wireless 1397) which although supported by the Linux b43 driver is not supported by Meego 1.0. Although Meego 1.0 has a new enough kernel (2.6.33.3), it is unfortunately not a simple case of using the firmware cutting tool to extract the firmware, the module itself is compiled out. This is Meego bug #287.

Your other (non-free) option is to use Broadcom’s STA driver. You’re going to need to yum install make gcc diffutils kernel-netbook-devel to build the module.

Finally if you’re looking to buy a netbook, also know that the trackpad is on this device is pretty frustrating under X due to the buttons being under the touch surface (it’s only slightly less frustrating in Windows 7, to be honest). Collabora X Guru Daniel Stone tells me support for trackpads with buttons under the touch surface is getting better so it’s a lot less annoying jumpy, but it still needs more work. I’ve been using an external mouse.

The Meego 1.0 People Panel

So Meego 1.0 for Netbooks shipped last week. Although I miss that tubby cat, Meego 1.0 is very visually attractive and quite nifty.

One of the really neat things about Meego is how it integrates messaging right into the interface. Unsurprisingly, this messaging is powered by Telepathy, the framework that makes communications into a service that you can use throughout your product. Collabora, with its team of Telepathic Ninjas, helped Intel with some of the Telepathy integration for this release.

Meego 1.0 People Panel
Meego 1.0 People Panel

The People Panel shows your available contacts on the left, and a list of your ongoing conversations on the right. Each conversation lists the number of unread messages.

This integration requires no code in Telepathy, and is all done using a Telepathy Observer (I’ve talked about Observers before). This will work with Empathy, or any other well behaved chat client (as it turned out that Empathy originally wasn’t well behaved, that had to be fixed, those fixes are in Empathy 2.30).

Mission Control allows any application to ensure a communications channel exists, and find an appropriate application to handle that channel. This means that double clicking on a user or ongoing conversation in the People Panel causes Mission Control to signal Empathy (the handler) to bring that conversation to the user’s attention (pop it up) or open a new window if required, even though the People Panel and Empathy are completely separate applications and completely unaware of one another. Again this will work with any well behaved chat client.

This same feature could easily be integrated into GNOME Shell or anywhere else. The code to implement this in Meego is free software.