[GnomeMeeting-devel-list] Ideas and considerations for the addressbook code



Hi,

in private mails (with quite big attachments since I provided some sample stupid code), �ic Bischoff found my code not that explicit concerning what I have in mind. Since I would like to keep things as opened as possible, I drop my text here :-)

Let's see if I can manage to give useful ideas.

***** BIG WORDS

Model - View - Controller


***** VIEWING (GENERIC)

We need to be able to present a book to the user. For that, the view needs to have a list of contacts (no, a single contact definitely isn't enough!). So we need a function call to get a list of contacts.

The problem is that this list will change during time (new contacts added, others removed, presence changed, status message changed, and the list goes on). So the view will need to be notified about it. Hence the idea that the book will have "contact-added" and "contact-removed" signals, and the contacts a "updated" signal.

In addition to that, there is an interesting special case to handle : you have a contact in a book, and this contact shows up in a search result. When you remove the contact from the book, we want to make it disappear from the list too. Hence a "removed" signal for contacts.

Now this is all nice, but what can we do if an addressbook contains millions of entries ? And if a search gives thousands of results ? In such cases, my stance is that the low level code should do something about it, since it is the one giving the problem. How can the high level code cope correctly with the situation anyway ? Only the low level code can say "Eh, I already made two hundred contacts go through the wire for that search, perhaps I should make it easy!".

The question to really ask, and to which I have no satisfactory answer is: "How do me make the low level tell the high level it had to cut the list ?".

***** VIEWING (CONTACTS)

The contacts should contain enough to be viewed from a generic view in the contacts window, and be shown in a search result. That won't prevent some other parts of the code to make a better use of them.

For example, in the contact window we will probably be able to see a contact's title and description, but not its detailed presence, while the main window will contain a much better and more specific view for the live contacts.

***** CONTROLLING (GENERIC)

Now, we want to be able to act on our objects ; say rename a book or a contact, subscribe/unsubscribe to its presence, etc.

The best thing to do is to be able to get menus for each of them. Notice the plural: we will certainly to have at least menu in the menu bar and a popup menu.

The first bad news about such menus is that they won't be generic : they will depend heavily on the specific type of object (no rename for avahi contacts, subscribe/unsubscribe only for XMPP contacts...). So we will certainly need some sort of shared actions that will be basic bricks for building menu (like the shared-actions.[ch] of my first round of proposals), that each implementation will mix as it sees fit.

The second bad news about them is that they won't be static either. They will have to update themselves following the object they are attached to. Say your nice XMPP contact is connected with a client which has VoIP support, but now connects with a no-VoIP client, and disconnects the first : we want the "Call" menuitem to disappear to reflect this.

So my proposition (no code yet) is that those menus will be obtained by subclassing of GtkMenu, register to get signals from the contact/book they are attached to, and use that to keep themselves up to date.

***** CONTROLLING (CONTACTS)

Let's try to be more specific:
in avahi-contact-menu.h, we would have:
GtkWidget *avahi_contact_menu_new (AvahiContact *contact);
and in gm-contact.h:
GtkWidget *gm_contact_get_menu_new (GmContact *contact);

This later function would be different in each implementation, which allows for example the avahi_contact_get_menu_new implementation to call avahi_contact_menu_new. The high level code called a generic function, but got access to a very specific implementation, which knows the full api of the specific contact, and hence will provide the best service.

***** CONTROLLING (BOOKS)

Perhaps the menu shouldn't be attached to the book himself, but to its view. That would allow to place things such as "Show offline contacts" in it. Mostly the idea would be to have controllers for both the model-as-model and its view-as-model.


***** ABOUT EVOLUTION-DATA-SERVER

The evolution-data-server api looks pretty good -- except that it seems to mainly handle static vcard-based contacts, where I would like to be able to handle things like.

For example, we find a nice contacts-changed signal, but in the EBookView api... not in the EBook api, which seems strange.

***** ABOUT LIBGAIM

I shriek everytime I read/think about that comment in blist.h (just before the declaration of struct _GaimBuddy) : "A buddy. This contains everything Gaim will ever need to know about someone on the buddy list. Everything." (sic).
and that one (before the declaration of struct _GaimContact) :
"A contact. This contains everything Gaim will ever need to know about a contact."
and that one (before the declaration of struct _GaimGroup) :
"A group. This contains everything Gaim will ever need to know about a group."

Notice that the comment before struct _GaimChat, although very similar, isn't so bad in my eye :-)

Notice too that although I find the way it is done inelegant, it still is very good and efficient to get the job done, and contains quite an impressive list of good ideas. (And it's more portable as ekiga, gasp!)

***** ABOUT LIBGALAGO

Why, why, oh why does it contain a GalagoList api which looks so much like a GList but isn't !?

Apart from that, I would say it looks nice, but is out of scope for what we want to do right now : it doesn't deal with addressbooks, but with persons as single.

"Using" it would be nice at some point.

***** LAST WORDS

Congratulations, comments and flames welcome, but flames will end in /dev/null.

Snark




[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]