Following on from group/category support, I've just merged support for setting and retrieving avatars/photos on Google Contacts from Evolution. There are still a few rough edges, but hopefully I'll get time to tidy those up before GNOME 3.2.
I'll be arriving on the 5th, spending a day hurriedly seeing absolutely everything there is to see in Berlin, then diving into the conference on Saturday. I'm leaving on the 12th.
For anybody interested in contacts, meta-contacts, individuals, personas and inventing words to make your software sound more impressive, there's a folks BoF happening at some point on Wednesday (not Thursday as the schedule says, since Travis has to leave beforehand). More details will follow, hopefully, in the libfolks talk on Saturday, 11:20–11:50 in Room 2002.
I'll be heading along to the IM, Contacts & Social hackfest next week at Collabora's offices. There, a plan for world domination by libfolks will be forged, along with plotting around GNOME's new SSO overlord system and work on the much-awaited GNOME Contacts.
Should be fun!
Relatedly, I've just released libgdata 0.9.0, which has sprouted support for OAuth 1.0 — so hopefully some GNOME Online Accounts goodness will soon make it into Evolution's Google Contacts and Calendar backends.
My work to add support for groups/categories to Evolution's Google Contacts address book backend has just landed, thanks to Milan Crha for reviewing it all. It should be available in GNOME 3.0, so people can categorise their contacts to their hearts' content!
I'm now working on making the backend properly asynchronous and cancellable, and also looking into adding support for contact photos.
So, after a year of blood, sweat and tears repeatedly appearing at exactly the wrong time to get my patches in, I've finally managed to commit my patches to Evolution and evolution-data-server to port it to use libgdata rather than its home-grown libgdata-google library. Since Evolution has switched to using CalDAV for its Google Calendar backend, libgdata is just used for the Google Contacts backend. This is the first outing into the big scary world of popular usage for libgdata's Google Contacts support, so any and all testing of the changes would be appreciated.
In the meantime, I'll get back to looking at adding support for any additional features/contact fields I can to the Google Contacts backend.
Work on libgdata is progressing nicely, and I've started on porting evolution-data-server to the shiny new calendar and contacts services provided by libgdata. One idea I recently had was to use the
G_GNUC_WARN_UNUSED_RESULT macro (gcc's
warn_unused_result attribute) on functions which return allocated data, to warn users of the library if they're not using the data, and thus leaking memory.
After a little research, I've found no real uses of that gcc attribute in this manner, which is rather surprising. Perhaps people think the effort of adding the attribute to all applicable functions is not worth it, given that 90% of the time, users of their libraries will correctly use the result of functions (if not free them)?
Anybody got any insights into the matter? I'll probably go ahead and add the attributes anyway, since there are definitely a few functions in libgdata which return allocated data when the user probably isn't expecting it.
It's about time to announce something I've been working on for about three months now: libgdata. It's a GLib-, libsoup- and libxml2-based library for accessing GData APIs, as used by most Google services. There already exist several such libraries in a variety of languages, but as far as I'm aware this is the first one written in C — and thus the first which is widely accessible to the GNOME stack. So far it has decent support for YouTube video queries, and the beginnings of Google Calendar support.
Having ported the Totem YouTube plugin to use libgdata, my next plan is to port the evolution-data-server Google Calendar backend as well. With that done, libgdata will hopefully be stable and fully-featured enough for people to get to work on starting to fulfil Rob Bradford's dream of tighter desktop integration with web services.