Re: [GnomeMeeting-devel-list] [RFC] New addressbook, evolution-data-server and internal contacts

["Damien Sandras" <dsandras seconix com>]

Le 5/3/2004, "PUYDT Julien" <julien puydt laposte net> a écrit:

>Hi,
>
>I want to try to describe what's the current situation in gm, and
>discuss things that could be done. Feel free to answer with corrections
>and/or new ideas!
>
>Contacts can be found in several places in gnomemeeting, and in
>different forms:
>* in the address bar, as a simple callto or h323 address;
>* in the calls history, where there is more information;
>* in the ils listing, with even more information;
>* in the internal addressbook, with basic information;
>* in the text-chat, as a simple h323 address.
>
>Those contacts are stored in various formats: as data in a gtk widget or
>as a simple string with fields separated by '|', for example. They can
>generally be used with drag'n drop, which is nice.
>
>The 1.00 code has several problems, that stem from this:
>* all components need to know the existence of others;

That's not right, they just need to know the format of data passed to
them.

>* worse, they need to know the internals of the others, to be able to
>get the data they want (see for example after line 284 of
>src/ldap_window.cpp for an example).
>

That's a problem you won't be able to fix with your new approach either.
You should read the GTK manual for drag-and-drop from a Tree View, or
drag-and-drop in general. What you see line 284 is just the callback
that is called when you receive data from a TreeView.

>The idea would be to unite things a little: if dragged contacts were of
>a known type, the code to handle them could be mostly shared, and the
>various parts of the code working with contacts wouldn't need to know
>about each other.
>

That's unfortunately wrong again. That would be the ideal situation
though.
The problem is that you only know what is dragged when you are in the
appropriate callback, and the only data available there to determine the
contact dragged is the TreeView itself, not an hypothetical vcard :(

>So the question is: which type of contact to use? The answer is, in my
>opinion, pretty clear: we would like to integrate with the rest of
>gnome, and for the rest of gnome, evolution-data-server is gonna be the
>standard.


Yes, small remark here : it has to be optional, ie you should be able to
do with or without evolution-data-server.

>
>I went to #evolution to discuss about it, and get some information; here
>is what I gathered:
>* the dragged contact will be of type "text/x-vcard", and contain the
>raw vcard text;

Good idea!

>* there are two types of contact that can be created from that
>information: EVCard and EContact (they are quite comparable, see:
>http://anoncvs.gnome.gr.jp/viewcvs.cgi/evolution-data-server/addressbook/libebook/e-vcard.h?view=markup and http://anoncvs.gnome.gr.jp/viewcvs.cgi/evolution-data-server/addressbook/libebook/e-contact.h?view=markup)
>* both of them have a field that can get an h323/callto url (search for
>"VIDEO" in the headers I linked to).
>
>Here are the questions I still have:
>* should gnomemeeting have no addressbook at all, and fully rely on

GnomeMeeting should have an address book. Don't forget people who won't
want to install E-D-S, don't forget windows either. Our address book
just should
be able to manage both our contacts and E-D-S contacts. Our contacts
being the short form of E-D-S contacts (ie less details, and only those
with an URL would be displayed).

>* how will speed-dial work?
>

If you keep an addressbook, that's not a problem, a speed dial is just a
quick link to an URL.

>Snark
>
>_______________________________________________
>Gnomemeeting-devel-list mailing list
>Gnomemeeting-devel-list gnome org
>http://mail.gnome.org/mailman/listinfo/gnomemeeting-devel-list