*** Bug 564589 has been marked as a duplicate of this bug. ***

This bug was already opened as bug #564589. Please take a look at its comments.

>> dragging files to the contact list

That would indeed be very helpful. My gf tried (and failed) to do exactly this just 2 days ago :)

Thanks for your branch, it works fine with files from Nautilus :-)

I would like to use drag & drop for a Tomboy plugin: when I drag a Tomboy note from the "All notes" window to a contact in the Empathy contact list, I would like Empathy to start a file transfer and, on my contact's computer, Tomboy to receive the file transfer channel and add the note in Tomboy.

To do that correctly, I want Empathy to request the file transfer channel with a specific ContentType property, so that the Channel Dispatcher on my contact's computer will dispatch the channel to Tomboy. Tomboy note files are "text/html" but I don't want Tomboy to handle all "text/html" files, only Tomboy notes. We can use something like "x-tomboy" as a pseudo mime-type. If my contact does not have Tomboy installed, Empathy would just handle the channel and save the file.

Ideally, there must be no Tomboy specific code in Empathy. It means the application source of the drag & drop must have a way to optionally specify the mime type of the file:
- if Tomboy specify "x-tomboy", Empathy will create the file transfer channel with the ContentType property set to "x-tomboy"
- if Nautilus does not specify anything, Empathy just choose the ContentType with g_file_info_get_content_type() as it does at the moment.

+void        empathy_send_file                           (EmpathyContact   *contact,
+                                                        GFile            *file);

An optional "gchar *content_type" parameter can be added, so the drag&drop source application can choose the MIME type, and NULL defaulting to g_file_info_get_content_type().

I just read that in your branch you use the XDND format "text/uri-list". With this format, the source application cannot specify the MIME type, but only a list of files. (Btw, your branch only transfer the first file of the list and forget the other files after the first separator "\r\n".) Do we need to invent a new XDND format ~"x-telepathy/file" to contain the uri and the mime type? It does not look to be an attractive solution.

At the moment, a drag & drop from Tomboy gives the uri 'note://tomboy/hash-of-the-note' and Empathy will fail to open that file. Empathy could understand that this uri means file '~/.tomboy/hash-of-the-note.note' (or better, get the content of the note over D-Bus, Tomboy exports everything on D-Bus) and MIME type 'x-tomboy'. But adding Tomboy specific code in Empathy is not an attractive solution neither.

Any better ideas?

All right, so let's say Tomboy notes were marked as text/x-tomboy-note.  This is the type of the data.  On the sending side, one of two things would have to happen: 1) Empathy is made to understand note: URIs and ask Tomboy for the note data, or 2) Tomboy advertises text/x-tomboy-note as a target type for drags, delivering the entire contents when that type is requested, and Empathy is made to understand that text/x-tomboy-note initiates a file drag.

In the first case, Empathy is special-casing an application-internal URI scheme.  In the second case, Empathy is special-casing a content type.  Note that Empathy doesn't initiate a file transfer for any other content types.  (Should it?  I suppose it could, although we'd have to make up a file name.)

I tend to think a more elegant way to handle this would be to make Tomboy do Telepathy.  It could have a button in the toolbar of a note to drop down a list of contacts you can send a note to.

Note that the only way to drag a note from Tomboy is from the search window.  So if you're looking at a note, it takes a few steps to get a draggable representation of that note.

(As for only taking the first file, I know, and there's a comment about that in the code.  What I think would be slick would be to offer to zip the files like nautilus-sendto does.  I looked into nautilus-sendto's code.  It hardcodes formats and constructs file-roller command lines, which I suppose is the best thing it can do.  If file-roller could provide a D-Bus interface, though, it would make this much easier to implement cleanly.)

After a discussion on #telepathy, a better solution: Tomboy should add a couple of files in /usr/share/mime-info to recognize files with regexp "*-*-*-*-*.note" as Tomboy notes, and g_file_info_get_content_type() will just return "application/x-tomboy" automatically. So no change is needed in Empathy.

Ping.  This is what's done so far on my branch:

* You can drag files to conversation windows.
* You can drag files to contacts in the contact list.
* Dragging both files and contacts in the contact list highlights the destination row or point, so you know what you're dropping on.

What I haven't done is investigate the drag interaction when you have a contact list inside a chat window, as in a multi-user chat window.  But I think the code as it stands right now is an improvement, and could be merged.  Could somebody review it please?

Thanks for your branch! Here is my review.

• Your branch doesn't "make check" because of a doc issue which has been fixed upstream. Please rebase it on top of master and be sure that "make check" passes
• DnD should probably be disabled on chat dialog when the connection has been disconnected
• One of your commit should include "#595226" so the release script will catch that you fixed this bug.

libempathy-gtk/empathy-chat.c

• Why are you calling gtk_drag_dest_unset() in chat_create_ui ?

libempathy-gtk/empathy-contact-list-view.c

• contact_list_view_drag_data_received: "sel_data = (const gchar*)"  should be (const gchar *)
• contact_list_view_drag_data_received: if success, gtk_drag_finish() is called twice. One with TRUE as success and one with FALSE. Is that expected?
• contact_list_view_drag_data_received: factor out code from each type of DnD to another functions. This function is already too big
• contact_list_view_drag_data_received: add some comments explaining the strstr/strchr stuffs
• contact_list_view_drag_data_received: gtk_tree_model_get will ref the EmpathyContact so you should unref it when you're done
• contact_list_view_drag_motion: static variables make me cry. What about having priv->file_targets and create it during the construction of the contact list view?
• contact_list_view_drag_motion: please document the path == NULL case. Also use GDK_ACTION_DEFAULT instead of '0' when calling gdk_drag_status(). 
• contact_list_view_drag_motion: add comments (and maybe split to different functions) the different code path of this function
• EmpathyContact is leaked here too

src/empathy-chat-window.c

• chat_window_drag_motion: same remark about the static GtkTargetList
• what's the logic of 	if (target == GDK_NONE) GDK_ACTION_COPY else  GDK_ACTION_MOVE ?
• chat_window_drag_data_received: "Only handle a single file for new"  for *now*
• chat_window_drag_data_received: lot of code seems copied from empathy-contact-list-view.c. Could we share it in some way?

I did some refactoring and rebased on master.  It's now on the "dndfiles" branch in my repo.  I believe I addressed all the points here.  Also, file drags are no longer accepted for offline contacts or contacts who lack the capability, for both chat windows and contact lists.

I also ran across a problem where the drag pointer doesn't update after GtkNotebook auto-switches tabs during a drag.  I opened bug #597620 against GTK+ for this.  It's a pretty minor problem.

From IRC conversations and code comments, I think the inteded behavior for dragging a contact to a chat window is that you open a new chat with that contact, unless you drag the contact to a MUC window, in which case dropping invites the contact.

This is not what actually happens right now (and I'm pretty sure I didn't change it).  Dropping a contact on a chat window always starts a new conversation with that contact (or moves the conversation for that contact to that window, if you already have an open conversation).  Thinking about it more, I think this is really the best thing to do, because it keeps the drag behavior predictable.

Nonetheless, I think drag to invite is mighty handy.  So I'm thinking that the contact list in a MUC window could be a drop target.  Dropping there would invite the contact.  This keeps drags to the window predictable while still providing the handy drag invite functionality.  Thoughts?

(In reply to comment #10)
> From IRC conversations and code comments, I think the inteded behavior for
> dragging a contact to a chat window is that you open a new chat with that
> contact, unless you drag the contact to a MUC window, in which case dropping
> invites the contact.

Agreed.

> Nonetheless, I think drag to invite is mighty handy.  So I'm thinking that the
> contact list in a MUC window could be a drop target.  Dropping there would
> invite the contact.  This keeps drags to the window predictable while still
> providing the handy drag invite functionality.  Thoughts?

This sounds like a good idea.

If you get into the area of upgrading 1-to-1 chats to MUCs it gets hairy, as it's pretty hard to do and protocols do it differently. Can you make the contact have a little + icon next to it if you're inviting, or something like that?

(On a similar topic, I'm supposed to be working on a spec extension for upgrading channels.)

(In reply to comment #10)
> Nonetheless, I think drag to invite is mighty handy.  So I'm thinking that the
> contact list in a MUC window could be a drop target.  Dropping there would
> invite the contact.  This keeps drags to the window predictable while still
> providing the handy drag invite functionality.  Thoughts?

Sounds same to me. Something cool would be to use a question mark pointer when drag is done while pressing the Alt button and display a menu offering different possibilities (as in Nautilus). Freel free to open another bug about this improvement.


chat_window_drag_data_received

		if (!EMPATHY_IS_CONTACT (contact)) {
we generally use contact != NULL in that case.
Also add a comment saying why the contact would be NULL (muc)

chat_window_drag_motion
Shouldn't you check if empathy_chat_get_remote_contact returned NULL?

contact_list_view_drag_motion
-		if (contact) {
+		if (contact &&

Our coding style is if (contact != NULL) (old code didn't respect this but better to fix it now we are changing this line :)

Currently 17 Empathy tickets are set as GNOME 2.30 blockers, hence mass-removing.
Guillaume: Please use normal Target Milestones instead. If you really think that this specific issue here is a 2.30 blocker then please restore the GNOME target and set corresponding importance values.

*** Bug 588689 has been marked as a duplicate of this bug. ***

Re-assigning to Shaun as he's responsible of the branch.

I addressed the points in comment 13, and rebased onto master.  There were actually quite a few conflicts.  I think they were mostly due to changes on master to use "time_" instead of "time" as a variable name.  I think I preserved the changes on master.

Since it's rebased, it's in a new branch in my repo: dndfiles2.

Awesome! I merged the branch to master. Thanks a lot for your work on this.

This problem has been fixed in the development version. The fix will be available in the next major software release. Thank you for your bug report.

*** Bug 608261 has been marked as a duplicate of this bug. ***