Abstract nonsense

As I already mentioned, I worked on revamping ekiga’s addressbook management those last months (yes, it’s long, but I only have spare time, first wrote GObject code, rewrote in C++/sigc+ — did I mention I have a family too?).

One of the goal of the framework is to give access to the same type of addressbooks as the current stable ekiga — that is of course evolution-data-server and LDAP, but also to KDE’s addressbook.

The most important thing is to display those contacts, but there are three other things we will want the user to do :

• add new contacts, which isn’t very complex since we basically want a name and an address but can give issue (see third point)
• remove contacts, which is trivial
• edit contacts, where things get more hairy

The reason why it gets hairy is that the number of different addresses ekiga can be interested in is quite large, and can be found in quite a few places — there’s obviously the badly named E_CONTACT_VIDEO_URL, but there’s also all of the E_CONTACT_PHONE_* !

Of course, one would think — like I did — that it was just a matter of calling the right api to get a wonderful edit window on the screen. But alas! It doesn’t seem to exist…

So we have openedhand‘s nifty contacts program, which implements a contact-editing window, and gnome’s integrated solution evolution, which implements a contact-editing window. Both based on evolution-data-server.

A quick inspection of the debian packages shows that there is a libedataserver and a libedataserverui, but only a libebook without a libebookui. A quick inspection of the api shows that in fact, libedataserverui contains ui portions for libebook — but no contact edition.

This is the reason why I just reported this as a bug. That won’t necessarily make the ball roll — the best would be if I could spare some time and prepare a patch. But I’m pretty hopeful showing there is an itch to scratch there will make someone move. Especially since there is ready-made code to build upon in two projects!