CODEWITHSUNDEEP
pythongtkpygtkdrag-and-drop
rsaw
rsaw

Reputation: 3537

pygtk troubles with drag and drop: file to GtkFileChooserButton

My app has a GtkFileChooserButton that you can use to open a chooser widget and pick a single file .. and then perform operations on that file. This works.

I've added drag & drop functionality to the button as well. It works, but it's buggy.

In short, the first dnd to the FileChooserButton triggers the file-set signal and appears to have worked, -- the name changes from "( None )" to the file's name and if you then click on the button, it pops up a chooser widget showing the proper file selected; HOWEVER, as you can see from the debug output below, get_filename() does not return the filename! Not the first time, anyway.

The second time we dnd a file onto the button (whether it's a different file or the same file again), all goes well and get_filename() returns the file's name. Why?

Here's the debug output from my program when I drag three files on to the button, one at a time:

[on_file-set] FileChooserButton.get_filename() output:
None

[on_file-set] FileChooserButton.get_filename() output:
'/home/ryran/Desktop/priv.txt'

[on_file-set] FileChooserButton.get_filename() output:
'/home/ryran/Desktop/kinamppost'

PS: When I did this, the 1st and 2nd dnd were actually the same file.

If you want to see the full app in action, it's at http://github.com/ryran/pyrite, and I'd love to post code, but there's not really anything to post!! I'm not doing drag_dest_set() because FileChooserButton already supports dnd. So ALL I'm doing is defining a cb for the FileChooserButton's file-set signal. So uhh.. here's that:

def action_chooserbtn_file_set(self, widget):
    print "[on_file-set] FileChooserButton.get_filename() output:\n{!r}\n".format(widget.get_filename())

For the record I also tried doing all this in concert with defining drag_dest_set, but came up with the same results.

What else to say? I'm starting to think this is a bug.

Upvotes: 1

Views: 514

Answers (1)

rsaw
rsaw

Reputation: 3537

Turns out this really is a GTK+ bug. Talked to a developer on IRC. He helped me realize that and then encouraged me to post a bug report, which I did -- https://bugzilla.gnome.org/show_bug.cgi?id=669718

Upvotes: 2

Related Questions