Re: [GnomeMeeting-devel-list] [DRAFT] Organization of the "find contact" task

[Damien Sandras <dsandras seconix com>]

Le lundi 29 mai 2006 à 21:47 +0200, Julien PUYDT a écrit :
> > 
> > I still maintain that this notion shouldn't be presented to the
> > programmer or to the user.
> 
> I maintain that the current code, on addressbook creation, gives me a 
> drop down list, and when I choose one item in it, shows me a form to 
> fill. What I propose is the same.
> 

That part is OK for me.

> The sources' names and tooltips are visible only on addressbook 
> creation. The rest of the time, you only see addressbooks' names. See 
> attached screenshot of test code.
> 

That seems OK, except the layout which doesn't matter yet.

[...]

> > I do not have to know it is a CallHistoryBook. If I have to know it is a
> > CallHistoryBook, it means I will have to "special case" a lot of code in
> > the current code, adding many "switch" statements or "if" statements.
> 
> Yes and no.
> 
> Yes, I want specific code to export the call history through DBUS, so I 
> want it available.
> 
> No, you don't need the "find contact" window to know it's a 
> CallHistoryBook. It knows it's a GmBook from a GmSource, and delegates 
> its management to the source (which knows the details). Look at the 
> sample code I pasted to show how the window can display any addressbook 
> with a very specific view, without knowing about how it's done!
> 
> Let's see it again :
> 
>   view = gm_source_create_view (source, book);
> 
>    (void)gtk_notebook_append_page (GTK_NOTEBOOK (carnet->priv->notebook),
>                                    view, NULL);
> 
> we only know that view is a GtkWidget*, source a GmSource* and book a 
> GmBook*, but still we'll have a nice display!
> 

Well, what if you have 2 views? (in terms of API).

> > I think it should be a prerequisite. Searching has to be done
> > transparently, without having to take care of where we are searching.
> > Look at how KAddressbook or Evolution-Data-Server are doing things. You
> > have several types of address books, but the API is the same for all of
> > them.
> 
> Do they show presence ? Do they have to care if a contact has an 
> authorize/revoke action ?
> 
> Tell me just one thing that you could put in GmContact and would work 
> for all types of contacts.
> 

Tell me just one thing that you could not put in GmContact and that
wouldn't work for one type of contact.

>  >
> > Such code would be bad. I'm really not convinced by this part of your
> > approach.
> 
> It isn't ; I sent you some sample code.

The sample code is not doing anything very useful yet.

If we want to discuss further, please show me sample code that :
- Search for "Damien Sandras" in all types of address books and returns
a list of results
- Imagine we have a callback triggered when some action is triggered on
the contact allowing to call him. Please show me the sample code of that
callback.

Thanks,
-- 
 _      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