Re: [GnomeMeeting-devel-list] Refactoring the addressbook code
- From: Julien PUYDT <jpuydt free fr>
- To: GnomeMeeting development mailing list <gnomemeeting-devel-list gnome org>
- Subject: Re: [GnomeMeeting-devel-list] Refactoring the addressbook code
- Date: Sun, 26 Mar 2006 16:36:58 +0200
Damien Sandras a écrit :
The address book has to stay. It is a way to store local contacts, and
to find new "remote" contacts using LDAP or any other mean.
Yes, that is what was settled.
Each contact belongs to groups. Each contact can even belong to several
groups using Evolution.
We would need to add a specific group. I do not have a good naming, but
let's call that group "ERoster" for now (Ekiga Roster).
When the user adds a contact to the address book, that contact is
identified by an URL. That URL can be H323, SIP, XMPP or anything else.
He can add the specific contact to the ERoster group. (We need to find
an intuitive way of doing this. A simple check box "Part of the roster"
might be enough).
I don't agree here : you're basically making the roster flat (ie : no
groups in the roster)! I'd rather see the roster become a real
addressbook, with groups being what ekiga now names "categories".
In the main UI, we have a Roster. That Roster displays all contacts from
the address book who are part of the ERoster group of contacts. They are
organized in groups, depending on which groups you have associated them
to in the address book (Family, Friends, ...). If we know that we can
have presence information, then we subscribe to presence events, and
update icons in the Roster. If not, the user is still visible, but
without presence information (eg: "Mom" sip:+32497973131 ekiga net).
Editing the Roster will bring the same popups than editing contacts in
the address book.
I would like to avoid tying the ui to ekiga : there *must* be a clear
separation between the backend and the ui, so the dbus component doesn't
play second-class citizen :-/
Notice that for the ui, gaim already has it, and it is easy to write a
prpl (protocol-plugin) for it that would show ekiga's roster.
That is not complex to do. However, I wonder, is there some GOOD roster
Widget that we can reuse, or not? No need to reinvent a Roster if there
are good ones available.
There is quite good roster ui code in gaim & gossip. Gaim's ui could be
used through dbus, and the gossip ui comes as gobjects so we could
"steal" it easily.
I also have great ideas for the UI, but I'll leave the surprise for
I will start working on the UI after 2.0.2 has been released. Because
even if we do not have presence information, having a roster with
contacts you call often is far more convenient than going into the
address book each time.
Yes, having a simple roster, then adding presence capabilities is the
way to go. I would say :
1) create a simple roster backend ;
2) export it through dbus to use gaim's ui ;
3) add our own ui to ekiga ;
4) add presence to the roster backend ;
5) upgrade dbus to export the presences ;
6) upgrade ekiga's ui to show the presences.
] [Thread Prev