Re: [GnomeMeeting-devel-list] Refactoring the addressbook code

[Damien Sandras <dsandras seconix com>]

Le dimanche 26 mars 2006 à 16:36 +0200, Julien PUYDT a écrit :
> 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.
> 
> Indeed.
> 
> > 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".
> 

You misunderstood my email. That is exactly what I was saying.

> > 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 would use gossip's roster then, but I dislike it.

> > I also have great ideas for the UI, but I'll leave the surprise for
> > later :-D
> > 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.
> 

I do not follow you. I wouldn't give the priority to DBUS and gaim's UI
either. I wouldn't use GAIM's UI through DBUS, I don't want to depend on
gaim.

> Snark
> _______________________________________________
> Gnomemeeting-devel-list mailing list
> Gnomemeeting-devel-list gnome org
> http://mail.gnome.org/mailman/listinfo/gnomemeeting-devel-list
-- 
 _      Damien Sandras
(o-     
//\     Ekiga Softphone: http://www.ekiga.org/
v_/_    FOSDEM 2006    : http://www.fosdem.org/
        SIP Phone      : sip:dsandras ekiga net
                         sip:600000 ekiga net