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



>
>No, that won't. The current code has to know that the source
>is a gtk tree view, and has to know it. What I propose is
>something like:
>src_widget = gtk_drag_get_source_widget (...);
>drag_url = g_object_get_data (src_widget, "vcard");
>...

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.

>
>No, see above.
>

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

>
>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.

>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 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.

I agree that passing standardized data is the way to do things, and that
is what currently happens. But I think you should *really* read and
understand how drag and drop works in GTK.

>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.

>
>Well, wait and see... We still have some cleaning to do, and
>for that we need to understand gtk's drag'n drop.
>


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.

What do you think?

Damien



[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]