GNOME Bugzilla – Bug 776483
Reusing FileChooserDialog causes wrong desensitisation of OK button + a pile-up of selection-changed events
Last modified: 2018-05-02 17:54:18 UTC
Created attachment 342460 [details] MCVE I'm having a strange issue with a FileChooserDialog that I reuse. Each time it gets run, it gets a new parent window, title, filter, and action set - and it also gets a suggested filename set. However, it doesn't seem to like this... If such a FileChooserDialog has previously been run() with ACTION_LOAD, and I re-run it with ACTION_SAVE, the OK button (GTK_RESPONSE_OK or _ACCEPT) is sensitive but does nothing on click (the dialog keeps running). If I move the focus to another file, the button goes insensitive. If I then move it again, the button becomes sensitive and works as expected. I'm not sure whether this depends on the call to set_filename, but if I leave that out, it just seems to do _other_ weird things, so! Attached is an MCVE. To reproduce, do the following: * Create a file at /tmp/fakefile.txt * Open this program * "Load" the file using the provided button and clicking "Go" in the dialog. * Now try to "Save" the file: * - you can't because the Go button is sensitive but does nothing * - you move to another file, and the button becomes insensitive * - you move back to fakefile.txt (or anything else), and finally the button works I can presumably work around this by just constructing and destructing the dialog each time - and indeed, this is what I was doing before, before I thought I'd be clever and reuse it... - but that seems a bit like giving up! Something it seems GIMP and many other people did with various bugs around reusing this widget before: https://bugzilla.gnome.org/show_bug.cgi?id=702853 Ideally we can eventually get to the root of these problems rather than just sidestepping them.
The problem obviously centres around the selection_changed stuff in gtkfilechooserwidget.c, as determined by using notify::sensitivity on the OK button, plus a callback that dumps a g_warning() and G_DEBUG=fatal_warnings And I just had to "cont" about 10 times... so something is causing a pile of changes to :selection-changed in the process of the dialog opening up and reapplying the previously loaded filename. More so, ever successive time I run() the dialog, the number of sensitivity change events goes up. And this occurs even if I comment out the code that sets the current directory/filename/entry name on the dialog. For example: OPEN dialog new sensitivity == 0 OPEN dialog new sensitivity == 1 new sensitivity == 1 new sensitivity == 0 new sensitivity == 0 OPEN dialog new sensitivity == 1 new sensitivity == 1 new sensitivity == 1 new sensitivity == 0 new sensitivity == 0 new sensitivity == 0 OPEN dialog new sensitivity == 1 new sensitivity == 1 new sensitivity == 1 new sensitivity == 1 new sensitivity == 0 new sensitivity == 0 new sensitivity == 0 new sensitivity == 0 [...] So given that this button (result of get_accept_action_widget()) is de/sensitised when :selection-changed fires, it seems something is causing an increasing number of changes to that property every time the dialog is run.
All of the :selection-changed emissions appear to originate at list_selection_changed() in gtkfilechooserwidget.c Doing an unselect_all() after hide()ing the dialog doesn't seem to make any difference; nor does ensuring the dialog's :select-multiple is FALSE. Seems like something is causing list_selection_changed() to be called more than it should, to an increasing extent every time the Dialog is opened.
-- GitLab Migration Automatic Message -- This bug has been migrated to GNOME's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.gnome.org/GNOME/gtk/issues/727.