GNOME Bugzilla – Bug 556165
Cannot differentiate between drag-data-get calls: was DnD finished (user released the button)?
Last modified: 2018-02-10 03:32:33 UTC
As I explained here[1], I think that it would be useful to have gtk+ send a signal to the source widget *after* the user releases the mouse click, but *before* the target widget gets the "drag-data-received" signal. [1] http://permalink.gmane.org/gmane.comp.gnome.gtk+.csharp/9077
Hey Owen, we talked about this yesterday in the summit. I'll post the patch I had before you pointed me out the problem about it.
Created attachment 120518 [details] [review] Initial proposal As Owen pointed to me, this patch has the problem that the launch of the new signal is done on a function that is run by the target app, not the source app. Owen, do you have any suggestion about the function in which I would move this call? Thanks.
Created attachment 120519 [details] [review] version #2 I believe this fixes the problem of the previous patch. If you see the signal emission in context, you'll notice that it's sent just after a drag_data_get is sent. Indeed, I would like to hook on that signal, but drag_data_get is sent in other places as well (before the user releases the button) so there's no way for me to differenciate between all the drag_data_get signals that are sent. That's why I think we need this new signal.
Comment on attachment 120518 [details] [review] Initial proposal Doesn't work for reasons discussed in person: emission is added in the destination application not the source application.
Comment on attachment 120519 [details] [review] version #2 Look cloer where you added the signal emission. I would strongly suggest testing your patches before submission. But I don't agree with using a signal. Adding: gboolean gdk_drag_context_drop_occurred(GdkDragContext *context); That you can call from your drag-data-get handler makes more sense to me. (I checked the nautilus code and this will work.... Nautilus gets the data twice ... once during the drag and once during the drop) There is still something about this that bothers me: if you send a list of files to Nautilus during the drag, what if Nautilus wants to look at the contents of those files during the drag, not just the names? I'm wondering if the better approach would be to have a new type of drag data that included not just the source URL's but also suggested target file names. (Would have to be discused/standardized on xdg-list)
(In reply to comment #5) > (From update of attachment 120519 [details] [review] [edit]) > Look cloer where you added the signal emission. I would strongly suggest > testing your patches before submission. Sorry, what do you mean? > But I don't agree with using a signal. Adding: > > gboolean gdk_drag_context_drop_occurred(GdkDragContext *context); > > That you can call from your drag-data-get handler makes more sense to me. Yeah, with current state of things, this seems a better idea. I'll cook a new patch, thanks. However, if we could break the API, I would suggest to remove the emission of drag_data_get in that context, replacing it with the new signal. Because a different signal makes much more sense documentation-wise (a novice developer with gtk+ will have more problems to find this gboolean function than a different signal). > > (I checked the nautilus code and this will work.... Nautilus gets the data > twice ... once during the drag and once during the drop) > > There is still something about this that bothers me: if you send a list of > files to Nautilus during the drag, what if Nautilus wants to look at the > contents of those files during the drag, not just the names? > > I'm wondering if the better approach would be to have a new type of drag data > that included not just the source URL's but also suggested target file names. > (Would have to be discused/standardized on xdg-list) > I'd agree with that. However, I think we should push both fixes upstream, one as long term solution an the former as a quicker one. Thanks for your feedback.
(In reply to comment #6) > (In reply to comment #5) > > (From update of attachment 120519 [details] [review] [edit] [edit]) > > Look cloer where you added the signal emission. I would strongly suggest > > testing your patches before submission. > > Sorry, what do you mean? Hah, sorry, I now know what you mean, I think I put my call in the wrong block (it happened only when only some DnD protocol was being used). Anyway, it was just a mockup and indeed it was useful because you could correct my approach on time ;) I'm going to attach a diff with my progress. It's not completed yet because I have some questions that maybe you can answer much quicker than me finding the solution! :)
Changing summary per new targets.
Created attachment 121885 [details] Draft for next version of the patch, please help This is unfinished. I have added the line "info->context.drop_occurred = ??;" where I think I have to change the internal field. My questions are: 1. How can I change it? If it's internal, I shouldn't expose API to change it, mmm. 2. Is that the right place?
We're moving to gitlab! As part of this move, we are closing bugs that haven't seen activity in more than 5 years. If this issue is still imporant to you and still relevant with GTK+ 3.22 or master, please consider creating a gitlab issue for it.