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

["Damien Sandras" <dsandras seconix com>]

>
>> 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.
>
>Hmmm... Can't the receiver just call
>gtk_drag_get_source_widget () to find the source, and then get
>the data from that?

That will just give the same problem than what you are discussing about.
The piece of code you are talking about just does a test to determine
the origin, now imagine you are using gtk_drag_get_source_widget, where
is the difference? You will still have to know the format/composition of
the source tree view widget to be able to get the URL from that widget
as the URL is placed at a different place in each tree view (calls
history, address book, ...).

I think you have misunderstood some basic here :
- the callback you are mentionning is triggered when there is a drag and
drop occuring from a tree view. In the sake of code reuse, the same
callback is reused for all tree views in gnomemeeting.
- when the drag is released, you copy the URL in the drag data. There is
a consistent format in the whole GnomeMeeting code for this.
- another callback is called on the widget where the drag is released.
That callback reads the data and calls the URL from the uniform data.

You suggest that the data format is not unique. That's not true.
You suggest that the callback you have indicated requires to know where
the drag comes from. That's right, and that's nothing you will be able
to change, you always have to know the format of the source widget to
know where teh URL is placed in that widget.


>
>When the user selects a contact in the list, isn't it possible
>to generate the vcard, and put it as data to the widget that
>is a drag source? The destination would then get the widget,
>and read the vcard? (even that sounds way too complex ; how
>would different apps be supposed to cooperate with such a
>terrible dnd scheme!?)

I find dnd in GTK hard to understand and to play with. Setting the VCard
as data of the widget is not something to do, because I can already
imagine corruption. What if there are 2 callbacks for 2 drags happening
at the same time?

>
>> Yes, small remark here : it has to be optional, ie you
>should be able to
>> do with or without evolution-data-server.
>
>For drag'n drop between different gnome apps, what is
>transmitted _must_ be compatible. So that will have to be
>generated from gm's own code (notice: from a GPL app to a GPL
>app, I guess we can copy-paste some code -- just making it
>openly, talking to the original authors, and with proper
>copyright assignments). Probably not a big deal, since most of
>gm won't need a full-featured contact.
>

Of course, I agree with this.

>> Good idea!
>
>Yes, raw = probably no need for a wide dependancy on e-d-s.
>
>> 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).
>
>Doesn't sound easy. How to sync both?
>


That's the real problem, but I don't know anything about EDS, so I
can't really discuss it. But I can't imagine forcing people to open
the Evolution Addressbook to be able to give GnomeMeeting calls.


>> >* 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.
>
>Even without addressbook, I guess having an association
>speed_dial->url would be enough.
>
>Snark
>
>Accédez au courrier électronique de La Poste : www.laposte.net ; 
>3615 LAPOSTENET (0,34?/mn) ; tél : 08 92 68 13 50 (0,34?/mn)
>
>
>
>_______________________________________________
>Gnomemeeting-devel-list mailing list
>Gnomemeeting-devel-list gnome org
>http://mail.gnome.org/mailman/listinfo/gnomemeeting-devel-list