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

[PUYDT Julien <julien puydt laposte net>]

On dim, 2004-03-07 at 14:41, Damien Sandras wrote:
> That is fully broken. You will have to protect things with mutexes or
> make sure the data is always coherent accross the code. That will also
> prevent drag-and-drop to happen from the main evolution address book,
> which is bad.

Yes, I know...

> Yes, see above. You propose to replace the current code by a pure hack.
> That is something hard to defend.

Agreed!

> >grep tells me that callback isn't reused: it is declared,
> >defined and used only in ldap_window.cpp. But it still needs
> >to know about the calls history!
> >
> Of course, as it is able to accept data dragged from the history to the
> address book.

Which means the code isn't "reused" like in "make that single function
used twice two functions used separately, and the problem goes away".

> >No. The data is passed around as embedded in gtk tree views,
> >or a gstring, and once passed, made into the "consistent"
> >format. The piece of code I pointed to is an example of that.
> 
> I don't understand what you mean.

What I mean is: what goes from the calls history to the ldap window
isn't the "consistent" format, or there would be no problem. What really
goes through is the tree view itself. If you're not convinced, try to
make the calls history's internal representation private, and you'll
see! (btw, this is the only obstacle that prevents me from writing a
patch for that).

> >What I want is to pass the common representation directly.
> >
> 
> Yes a object data, and it is a very bad way of doing things. It will for
> example give problems when dragging from an external source as the
> external source won't be able to put data in a GM object.

Agreed.

> I agree that passing standardized data is the way to do things,

Agreed.

>  and that
> is what currently happens.

No, the internal structure is passed around, /then/ some standardized
data is made from that.

>  But I think you should *really* read and
> understand how drag and drop works in GTK.

I have read, and it is quite complex.

> >I'm asking for directions on #gtk, because the scheme I
> >propose above allows to ignore the format of the source
> >widget, but still needs the source widget to do something
> >special when the drag begins, ie: it wouldn't work for
> >cross-apps drag'n drop.
> 
> That's what I explained above, we agree.

Ok.

> I wonder, Julien, if we shouldn't begin by doing a DBUS component for GM
> instead of trying to fix drag-and-drop. DBUS is ready and usable in
> Debian, not E-D-S. It means we should perhaps wait for EDS to be more
> mature.

Yes, E-D-S isn't there yet, but to clean the code, getting the ldap
window to stop using the internal representation of the calls history is
necessary... and drag'n drop is one place where that fails.

Snark