Re: [GnomeMeeting-devel-list] [DRAFT] Organization of the "find contact" task
- From: Damien Sandras <dsandras seconix com>
- To: GnomeMeeting development mailing list <gnomemeeting-devel-list gnome org>
- Subject: Re: [GnomeMeeting-devel-list] [DRAFT] Organization of the "find contact" task
- Date: Mon, 29 May 2006 21:57:32 +0200
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
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]