GNOME Bugzilla – Bug 669718
FIRST dnd to GtkFileChooserButton fails
Last modified: 2018-02-10 03:41:59 UTC
FileChooserButton supports drag and drop, so.. if you create a FileChooserButton widget and connect the file-set signal to a cb like this one: def on_file_set(w): print "[on_file-set] FileChooserButton.get_filename() output:\n{!r}\n".format(w.get_filename()) You will likely see that the first time (after launching your app) that you perform a dnd onto the button, get_filename() will return None. All subsequent drag & drops will succeed and cause the dropped filename to be printed. To see this in action, you could check out my app at http://github.com/ryran/pyrite but that shouldn't be necessary.
Forgot to add the version info. (I think I edited the bug, but in case that doesn't go through: 2.24)
More info: I noticed something important while implementing cmdline argument parsing in my application. .... I have concluded that this actually has nothing to do with drag & drop, though that is the worst casualty. You can achieve the exact same buggy results you get on the first DND by simply calling a FileChooserButton's set_filename() method directly, as long as you do it before clicking on said button.
Found a bug report that I think illuminates why this is happening. Added to "See Also".
Additionally: I need to edit what I said in Comment 2: The last paragraph isn't quite right. It should read: You can achieve the exact same buggy results you get on the first DND by simply calling a FileChooserButton's set_filename() method directly -- the file is apparently set, but (according to what I understand from a post by Federico in another bug report) it is pending... in short, it won't REALLY be set until you open the FileChooser and press OK.
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.