Facebook and the N900 address book

The N900 address book can merge multiple contacts into a single entity: if you have a friend that has a phone number, an email address, a Jabber user name, a MSN one and so on, then you can merge all of the different entities into a single meta-contact.

Locally stored details and an IM user name in the same contact

The different IM contacts are tracked through their username and should be immutable^[1], but yesterday Facebook changed all the IDs from something like “u123456789@chat.facebook.com” to “-123456789@chat.facebook.com”. For the address book this means that all the previous contacts were deleted from the IM roster and new contacts were added, so you get duplicate contacts. Moreover, when a contact is removed from the roster we leave the IM user name in the contact details, if you click the button you can add the contact back to one of your rosters. In the Facebook case this means that you end up with all of your meta-contacts with a useless button that cannot do nothing.

The fix for this is to remove the old IDs and merge your contacts again, simple but tedious. A better way to do it is to be patient and wait until I finish a program that will do it for you in a few click

Update: I finished and release the program, see my blog post about Facebook migrator.

[1] Actually, some changes in the IDs are possible for normalisation purposes; if you add “FooBar@example.COM” it will become “foobar@example.com” in your roster. (And yes, the normalisation is buggy in PR1.1, but it will be fixed in PR1.2.)

GTK surprises on Maemo

Sometimes the creation of the contact chooser used on the N900 can be slow so, using callgrind and kcachegrind, I tried to understand what is the source of the slowness. This lead me to find some unexpected, and apparently undocumented, differences between upstream GTK and the Maemo version.

The Maemo 5 contact chooser

The widget contains a GtkTreeView that uses a model with just one column for the contact objects. How can its creation be so slow? To my surprise most of the time was spent decompressing the avatar images!
The avatars of the contacts are loaded, scaled and cropped in the cell data function of the GtkTreeViewColumn as, for various reasons, we cannot cache on disk the resulting image or generate it before the creation of the widget. Following calls of the cell data function for the same row won’t need to generate the avatar anymore. Doing non-trivial operations in the cell data function is not the nicest thing to do, but this should not be a problem as the cell data function is called only for the visible rows, right? No, at least not on Maemo!
To verify it just try this example program: on Maemo the cell_func() function is called once per item in the model plus once per visible item, elsewhere only once per visible item.

After a bit of investigation together with Claudio, we discovered that on Maemo there is a function called gtk_&#8203tree_&#8203view_&#8203column_&#8203get_&#8203cell_&#8203data_&#8203hint() that returns GTK_&#8203TREE_&#8203CELL_&#8203DATA_&#8203HINT_&#8203KEY_&#8203FOCUS, GTK_&#8203TREE_&#8203CELL_&#8203DATA_&#8203HINT_&#8203SENSITIVITY or GTK_&#8203TREE_&#8203CELL_&#8203DATA_&#8203HINT_&#8203ALL. The hint tells you why the function was called; in the example code the function is called on the hidden rows only to get their sensitivity so there is no need to set the “pixbuf” property of the cell at this point.

Just this tiny change in the address book code makes the contact chooser open much faster if you have a lot of contacts with big avatars, like the ones that Hermes creates. On the other hand the delayed loading made the scrolling become non-smooth
To fix the scrolling I had to implement some asynchronous loading of the avatars. The contact chooser now tries to load as many avatars as possible in idle moments and also tries to load first the avatars for the contacts that the user is more likely to see. The results seem quite good; now the contact list is fast, scrolling is smooth and the delayed loading of avatars should not be visible in normal cases.

Thanks Barclays…

I cannot understand if this email that Barclaycard (it’s not a scam, the email really comes from them) sent me is a sick April Fools’ joke or what:

Dear Mr Barisione,

You were recently upgraded to a Barclaycard Cashback card.

As you’re registered with mybarclaycard to manage your account online, we’d like to let know about a technical issue that means you will not be able log in to your account. We’re working to resolve this issue, but it will take until 1st June 2010.

[…]

If it’s a joke I want to stop using their services, if it’s not do they really need 2 months to fix this issue? This plus receiving fraud prevention phone calls every time I use the Barclays debit card in a shop (it happened three times in the last two weeks, twice just yesterday) and getting the transaction blocked makes me really want to change bank.
Suggestions for a decent bank in the UK? For now the only suggestion I got was Nationwide.

jid-to-email

During the Christmas holidays I managed to find some time to write a couple of small programs related to the address book on the N900; they are nothing too fancy (no UI, no proper packaging, not the best code quality, etc.) as I wrote them for my personal use, but I still think it could be useful to share them with other people.

The one I’m talking about today is a simple command-line utility that adds an email address to your contacts based on the Jabber ID (or on the ID of other protocols). This is very useful to me as in Collabora we all have a roster automatically filled with the other Collaborans, this way I can automatically have their email addresses in my address book.

This cannot be done automatically for all the contact as, usually, it’s not true that a Jabber ID is also a valid email address (for instance it’s not true for jabber.org users), but it’s true at least for the GMail and Collabora servers.

If you want to try jid-to-email get the already compiled arm executable or the source code. Remember to take a backup before trying it, I don’t want to be blamed if something goes horribly wrong .

The program accepts two arguments: the vcard field for the IM protocol and a regular expression. For instance, if you cd to the directory where the program is and do “./jid-to-email X-JABBER @collabora.co.uk”, an email address will be added to all the contacts that have a Jabber ID containing “@collabora.co.uk”. Similarly “./jid-to-email X-JABBER ‘@g(oogle)?mail.com’” will add an email address to all the contacts with a Jabber ID containing “@gmail.com” or “@googlemail.com”. You could also try using “X-MSN” to do the same thing for contacts that use their GMail address as MSN ID.

Please, let me know if you know any other server where the Jabber ID is always a valid email address.

By the way, this week-end I’m going to Brussels for FOSDEM: hope to meet a lot of GNOME people there!

Some lovely people out there

Some lovely guy sent me this email:

From:    ****@gmx.de
Subject: Freedom!

Take your closed source crap out of this planet, nobody cares about it.

-- 
Freedom Lover
-- 
Jetzt kostenlos herunterladen: Internet Explorer 8 und Mozilla Firefox 3.5 -
sicherer, schneller und einfacher! http://portal.gmx.net/de/go/chbrowser

Note the irony of using an email service that adds to your email an advertisement for Internet Explorer…

Early Christmas

It looks like Santa Claus arrived early for the Collabora employees

N900 pyramid, and sadly some of them didn’t arrive yet

New #empathy IRC channel

In the last months the traffic on the #telepathy IRC channel on Freenode has been constantly growing, reaching the point where communication among developers is difficult and, at the same time, some new Empathy users are scared and don’t talk on the channel. This is why we just created a new #empathy channel on GIMPNet (irc.gnome.org) for all the empathy users, while #telepathy will be used for development-related discussions.

See you all on #empathy!

Contacts on Maemo

After the Maemo Summit the details on the address book application and framework in Maemo 5 are finally completely public so I can openly talk about what I worked on during the past year and, even better, I actually have a smartphone that runs this software! (Thanks to Nokia that gave out 300 N900s, but I will talk about this in my next post)

Contacts on the N900

Contact details

As you can see from the screenshots, the Contacts application has everything you would expect from a normal phone address book but it also tightly integrates IM. Your local, Jabber/GTalk and Skype contacts will appear in the same address book and, if you have a friend on multiple IM protocols, you can easily merge all the contacts into a single entity.

My main task has been making the component responsible for the IM part of the address book work properly, this component is an evolution-data-server backend (recently released under LGPL) that acts as a bridge between the Telepathy IM framework and evolution-data-server. See the README file for more details.
Sadly the library on top of evolution-data-server that does the magic contact merging and contains the widgets used on Maemo is not open, but there is some hope for it.

Address book components

At the Maemo Summit I also gave a talk on Telepathy and how it’s used on Maemo, both for messaging/VOIP and for the contacts integration. The slides are available in PDF or in OpenOffice.org format (but for some reason colours look wrong in some recent versions of OpenOffice).

More GList anti-patterns

Ross, your examples are not as bad as something I found in some code I had to fix recently:

GList *list = e_vcard_get_attributes (evcard);

for (list = g_list_first (list);
     list != NULL;
     list = g_list_next (list))
{
         /* Do something */
}

for (list = g_list_first (list);
     list != NULL;
     list = g_list_next (list))
{
         /* Do something else */
         g_object_unref (list->data);
}

g_free (g_list_first (list));

“Surprisingly” it was not working, but at least it was not leaking memory as the return value of e_vcard_get_attributes is not supposed to be freed

Parsing names

In the last weeks I have been asked several times to modify some components I’m working on to add the ability to split a full name in its components (first name, family name, etc.).
It looks like most people have great expectations about this working correctly but they get annoyed when it fails, and you can be sure it will fail. It will fail because it’s impossible to parse a name correctly, for instance:

Full name	First	Middle	Last
Barack Hussein Obama	Barack	Hussein	Obama
Pier Silvio Berlusconi	Pier Silvio		Berlusconi
José Rodríguez Zapatero	José		Rodríguez Zapatero

How can you do this automatically?

This becomes particularly silly if you cannot be sure that the string you are going to parse is actually a full name, for instance don’t try to parse a chat nickname. It’s true that gmail/gtalk uses your full name by default, but this is only a default and it’s true only for gmail.

To cut a long story short, please please please don’t try to parse names. You can see by yourself how hard it is, even if I’m just considering western-style names.
If you still don’t trust me here’s a quote from e-name-western.c, i.e. the file that does name parsing in libebook :

* <Nat> Jamie, do you know anything about name parsing?
* <jwz> Are you going down that rat hole? Bring a flashlight.

On a side note when you are trying to understand why some code is broken you can find some funny commits, like the great EDS purge

Update: I found this “serious” bug in e_name_western_parse .

Marco Barisione's blog

Author: barisione