GNOME Bugzilla – Bug 350665
Gedit tab bar should support dropping files
Last modified: 2011-02-04 16:11:04 UTC
The empty area beside the open tabs does not support dragging and dropping files to open them. The tab bar is a natural place to drop files, and it's strange to have this one area that does not support drag and drop. The tab for the file could also open where the file was dragged. Other information:
which version of gedit is that? It should definately work with gedit >= 2.14 and it works on my machine
This is with gedit 2.14.3 on Gentoo.
On 2.15.7 it does not work too. Dropping works on the document and on the toolbar, but not on the notebook.
Joakim, do you have gtk 2.10? I wonder if it's the new GtkNotebook features that are preventing the drop...
Ok, I've found out that it was GtkNotebook not allowing other widgets up in the hierarchy to run their DnD handlers, I'm attaching a patch to make GtkNotebook swallow DnD-related events only when it's strictly necessary. I've been testing it with gedit, ephy & co and seems to work Ok. May I commit it?
Created attachment 71615 [details] [review] patch, fixes bug
The last time I discussed this with Owen, he told me that drag targets are not supposed to propagate events up the hierarchy. We need look at the implications of allowing that
I think the situation with GtkNotebook is a bit tricky, as it's only supposed to handle "GTK_NOTEBOOK_TAB" targets, but (due to gtk_drag_dest_set_track_motion) also interacts with any other target, and swallows all those events. IMHO what Owen says is right as a rule of thumb, but here GtkNotebook is only interested in any "unknown" target for the switch-tab-during-dnd-hover feature and swallowing those events too sounds slightly wrong to me. swallowing the "GTK_NOTEBOOK_TAB" target sounds very appropriate.
No real opinion. The original idea I had was that drop zones should be static: - They don't depend upon the type of the dragged object - They don't depend on the contents of the dragged object This was to prevent dropping from suddenly doing something unexpected if a particular drop type wasn't supported. But you could argue the other way and say that drops propagating is useful in some cases. Note that drops aren't going to propagate back up the chain across correctly across a Plug/Socket even if you implement it within GDK (without significant protocol changes), but that is pretty much a corner case.
I'm fine with allowing this for notebooks.
Thanks a lot, I've just committed it to trunk :) 2007-05-18 Carlos Garnacho <carlos@imendio.com> * gtk/gtknotebook.c (gtk_notebook_init) (gtk_notebook_drag_motion) (gtk_notebook_drag_drop): Allow widgets up in the hierarchy to run their DnD handlers if the target doesn't match with anything the notebook manages. (#350665, Joakim Lundborg).
*** Bug 424432 has been marked as a duplicate of this bug. ***
*** Bug 371443 has been marked as a duplicate of this bug. ***