If you instantiate a GtkFileChooserButton, connect to the "selection-changed" signal, then call gtk_file_chooser_set_current_folder() on it with some new directory path, a strange thing occurs [when the main loop fires up].

You get *two* hits on "selection-changed" and *zero* hits on "current-folder-changed". I have a hard time understanding why that would be, especially since no file has been selected, and the folder most certainly changed.

I realize that all the GtkFileChooser signals are marked as "somewhat internal" and "you shouldn're really have to touch these", but since GtkFileChooseButton _isn't_ a Dialog, you can't be 'running' it and waiting for the result code, can you?

In all other respects, exposing "selection-changed" has been fine, so I'm hoping that there's just some horrible mixup somewhere.

[I first noticed this when we did the language binding of FileChooser and friends in java-gnome 4.0.2. Vreixo Formoso Lopes, the person who actually contributed our code for FileChooser's setCurrentFolder(), created a C test case that duplicates the situation. I've asked him to attach his code to this report]

AfC