After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 695216 - GtkFileChooserButton doesn't update properly on combo box changes
GtkFileChooserButton doesn't update properly on combo box changes
Status: RESOLVED FIXED
Product: gtk+
Classification: Platform
Component: Widget: GtkFileChooser
3.7.x
Other Linux
: Normal normal
: ---
Assigned To: gtk-bugs
Federico Mena Quintero
Depends on:
Blocks:
 
 
Reported: 2013-03-05 14:06 UTC by Jonathan Matthew
Modified: 2013-05-13 02:47 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
update the button's state, not the internal dialog's state (1.73 KB, patch)
2013-03-05 14:20 UTC, Jonathan Matthew
none Details | Review

Description Jonathan Matthew 2013-03-05 14:06:49 UTC
Currently, when you select a folder from the combo box, GtkFileChooserButton emits current-folder-changed but gtk_file_chooser_get_current_file() does not return the new location. The following python thing demonstrates the problem:

#!/usr/bin/env python
from gi.repository import Gtk, GLib
w = Gtk.Window()
fcb = Gtk.FileChooserButton(title="hi", action=Gtk.FileChooserAction.SELECT_FOLDER)
w.add(fcb)
w.show_all()

def changed(fcb):
        print fcb.get_current_folder_uri()
fcb.connect("current-folder-changed", changed)

ml = GLib.MainLoop()
ml.run()

When you select a folder from the combo box, it just prints 'None' rather than the folder selected.

I think this is because combo_box_changed_cb updates the internal dialog but not the file chooser button itself. The update methods either update the internal dialog or ensure it will be updated when it becomes active, so I can't see why it would update the internal dialog here.
Comment 1 Jonathan Matthew 2013-03-05 14:20:58 UTC
Created attachment 238133 [details] [review]
update the button's state, not the internal dialog's state

This makes things work properly for me, and doesn't break any of the tests.
Comment 2 Adam Dingle 2013-04-01 11:06:28 UTC
See also bug 696498, which describes a similar (possibly duplicate) problem.
Comment 3 Matthias Clasen 2013-05-13 02:47:57 UTC
This change has already  been made in master