GNOME Bugzilla – Bug 118100
Rethink drag site propagation
Last modified: 2015-02-18 00:33:11 UTC
After I changed all my gtk_text to gtk_textview I noticed that drag and dropping files to my program did no longer work. When the mouse button is released when the mouse cursor is on a text entry or textview, the drop is refused, but when it's on the toolbar for example it still works. This is a major problem since most of the area in my main window is text.
Created attachment 18632 [details] a testcase
Test testcase confirms Manuels observation. The window accepts text/uri-list. When trying to drag a file from Nautilus, it is accepted over the button (which isn't a drop site) and over the colorselection below the button (which is a drop site, but accepts only application/x-color), but not over the entry, the textview or the embedded colorselection. I guess this is because the colorselection use GTK_DEST_DEFAULT_MOTION while the entry and the textview don't.
Here is a patch which makes GtkEntry work as a nested drop site without preventing drops for other types on the parent site.
Created attachment 18638 [details] [review] gtkentry patch
This stuff is non-obvious. I guess some doc additions regarding nested drop sites are in order. What I think I have understood so far is that the GTK_DEST_DEFAULT_ handling doesn't really support nested drop sites.
The principal is that the hierarchy of drop sites *does not* depend on whether a drop site accepts a particular drop or not; a widget is either a drop site or isn't a drop site; dropping on the same place in the window always goes to the same widget. (or same widget sub-part, like an icon) I have no idea what's wrong with the color picker button (haven't tried the test case out) - gtk/gtk_drag_dest_motion.c is pretty straightforward; it *always* returns TRUE if the GTK_DEST_DEFAULT_MOTION flag is set. Return value - is this widget a drop sight FALSE - No TRUE - Yes In the case of a return of 'TRUE', gdk_drag_status() must be called. GTK+ takes care of it if GTK_DEST_DEFAULT_MOTION is set, otherwise the app/widget is responsible. Various people have complained about not being able, to, say drop a file URI anywhere on a widget with embedded URI's, so perhaps we should think about a future change here, but there are various problems with doing so. - It's never going to work "as expected" with plug/socket embedding, since once the drag has been set to the plug, it can't come back. - We allow widgets to accept drops or not depending on the *data* of the drag, but to do this, you have to ask for the data, return TRUE, and when the data returns call drag status; so you can't have propagation up to a parent widget because you've already returned TRUE.
Hmm, so that feature simply isn't there. I thought it would be a natural thing to ask for. And its not terribly hard to implement as the gtkentry patch above shows. You're right though that it will only ever work for type-based filtering, not for data-based filtering. And it probably can't be made to work for embedded windows. But still, being able to drop a file anywhere on a text editor to open it looks like a natural way to use dnd with it, and having to derive from textview just to add a new dnd target seems overkill. Turning this into an enhancement request then. Btw. drop site nesting only seems to work for the color selection because the color selection itself isn't a drop site, only the color swatch/palette entries. If you drop on those places, it doesn't work either...
To stimulate the rethinking, it's still more a bug than an enhancement IMHO, because there is no workaround. Such is what I need to put in my manual: "When you drag and drop files onto the main window, you can only aim at the toolbar or statusbar. Be careful not to drop on the output text or command line, because it won't work on those places."
time to close this