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



Le mardi 28 mars 2006 à 16:14 +0200, Julien PUYDT a écrit :
> Damien Sandras a écrit :
> > Le mardi 28 mars 2006 à 14:56 +0200, Julien PUYDT a écrit :
> >> Damien Sandras a écrit :
> >>> Le mardi 28 mars 2006 à 14:47 +0200, Julien PUYDT a écrit :
> >>>> Jan Schampera a écrit :
> >>>>> What I didn't want at all
> >>>>> (and didn't do) is to connect that composite widget directly to the
> >>>>> managers of OPAL. That makes no sense to me. Some middle-layer will be
> >>>>> needed for that (as usual), to operate as an interface between both
> >>>>> layers.
> >>>> Agreed!
> >>>>
> >>> Agreed too. Just let's do the GTK+ part of the roster for now.
> >>> Then let's do the OPAL backend for SIP Presence.
> >>> Then we can glue them together.
> >> I would say :
> >> - first agree on the interface of the gobject roster backend ;
> >> - then write a boiler-plate implementation of this one ;
> >> - then write the gtk code which will display it in ekiga.
> >>
> > 
> > That's step 1 of my proposal with more details :-D
> 
> I would say we need to be able to :
> - ask the list of contacts ;
> - ask to modify a contact in the roster (addition is a simple 
> modification) ;
> - ask to remove a contact from the roster.
> 
> It would be the only methods. The roster would know two signals:
> - contact-updated
> - contact-deleted

You will never find a backend that signals when the contact is updated
or deleted. So you will have to artificially trigger those signals,
which I do not like.
-- 
 _      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




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