GNOME Bugzilla – Bug 340835
set_filename() docs should mention that it is asynchronous
Last modified: 2018-02-10 03:23:50 UTC
Please describe the problem: The documentation says: "gtk_file_chooser_set_filename () ... Sets filename as the current filename for the file chooser." "gtk_file_chooser_get_filename () ... Gets the filename for the currently selected file in the file selector" "gtk_file_chooser_set_current_name () ... Sets the current name in the file selector, as if entered by the user... If you want to preselect a particular existing file, you should use gtk_file_chooser_set_filename() instead." [http://www.gtk.org/api/2.6/gtk/GtkFileChooser.html] Therefore, it would appear that calling set_filename() and then get_filename() on a newly created file chooser, using the name of an existing file, should return that file name from get_filename(). However, it does not seem to, because the following code fails: The following code fails: Steps to reproduce: GtkWidget* foo = gtk_file_chooser_dialog_new( "hello", NULL, GTK_FILE_CHOOSER_ACTION_OPEN, GTK_STOCK_CANCEL, GTK_RESPONSE_CANCEL, GTK_STOCK_OPEN, GTK_RESPONSE_ACCEPT, NULL); char* expected = "/etc/issue"; gtk_file_chooser_set_filename(GTK_FILE_CHOOSER(foo), expected); char* actual = gtk_file_chooser_get_filename( GTK_FILE_CHOOSER(foo)); assert(actual != NULL); assert(strcmp(expected, actual) == 0); Actual results: Assertion failure on actual != NULL. Expected results: actual points to a string with the same contents as expected (i.e. "/etc/issue"). Does this happen every time? Yes Other information: If this is fixed in a newer version of GTK, is there any way to work around it in older ones? I really want to control what gtk_file_chooser_get_filename() will return. This is part of a unit testing framework, and I don't want to modify the application under test. gtk+2.0 2.8.6-0ubuntu2.1 Ubuntu Breezy Badger
This is a bug in the documentation. The file you put in set_filename() won't actually be selected until the chooser shows up and it loads the appropriate folder. So, get_filename() won't return meaningful results until the file chooser has emitted the "selection-changed" signal.
Hi, Thanks for explaining the bug. For the unit test framework, which helps with writing unit tests for GTK applications, I need to be able to fake/fix the selected file name in the file chooser without showing it. The best way to do this seems to be to set_filename() and then suppress the display of the actual dialog box. As you pointed out, this doesn't work at present. However, for me it would be far preferable to fix it so that it does work, rather than simply document the fact that it's broken. What do you say, can it be fixed properly? It shouldn't break any backwards compatibility since this is such a corner case for normal usage. Cheers, Chris.
I think you're trying to write a unit test for something that can't be tested in the way you want to test it :) A file chooser is pretty "dead" while it's not being shown. It tries to delay everything as much as possible so that it can avoid re-loading directories. When you call set_filename(), the chooser remembers that filename as a "pending selection". Only when the file chooser is shown to the screen does it actually go and visit the file and its parent folder. That is when you can call get_filename() and get meaningful results. Check out the tests in gtk+/tests/autotestfilechooser.c - that's the kind of tests that we *can* do. They are not complete, but it's a start.
What would be wrong with get_filename() returning the "pending selection" when the dialog has never been shown? Surely that does not require loading any libraries? And surely it makes more sense than returning NULL? There _is_ a selection, even if it's "pending".
(In reply to comment #4) > What would be wrong with get_filename() returning the "pending selection" when > the dialog has never been shown? Surely that does not require loading any > libraries? And surely it makes more sense than returning NULL? There _is_ a > selection, even if it's "pending". I'll gladly review a patch for that :)
Thanks Federico! I'm trying, but I'm a bit lost in the GTK source. I can see the following in gtk/gtk/gtkfilechooser.c: gchar * gtk_file_chooser_get_filename (GtkFileChooser *chooser) { gchar *utf8_filename = gtk_file_chooser_get_filename_utf8 (chooser); gchar *retval = g_locale_from_utf8 (utf8_filename, -1, NULL, NULL, NULL); g_free (utf8_filename); return retval; } But I cannot for the life of me find out where gtk_file_chooser_get_filename_utf8 is defined. Google searched only turn up mailing list archives of discussions about the introduction of the _utf8 forms. Can you point me in the right direction please? Cheers, Chris.
Eep, you are looking at the wrong function. What you really want is gtkfilechooserdefault.c:gtk_file_chooser_default_get_paths() - that's the core function to get the currently-selected path.
Created attachment 87539 [details] test program pops up a chooser dialog with a button, clicking the button does _set/_get() filename and shows the results
This bug/feature has bitten me too. I think it's actually worse than Chris described: you get the NULL even if the chooser is shown. My application broke because I was doing gtk_file_chooser_set_current_name(), then gtk_file_chooser_get_filename() without going back to the main loop. This used to work as expected, but now gtk_file_chooser_get_filename() will often return NULL. I've attached a test program. If I run this and click the button, I get: gtk_file_chooser_set_filename("/tmp"); gtk_file_chooser_get_filename() == "(null)" while (g_main_context_iteration (NULL, FALSE)) ; gtk_file_chooser_get_filename() == "(null)" I guess this is because the first time you set the filename it will change directory, and this needs an extra couple of loops around the selection and FS backend. The next time I click, the chooser is already in /tmp, and I get: gtk_file_chooser_set_filename("/tmp"); gtk_file_chooser_get_filename() == "(null)" while (g_main_context_iteration (NULL, FALSE)) ; gtk_file_chooser_get_filename() == "/tmp" Which is better, but still not ideal, in my opinion. I've had to change my application to always do "while (g_main_context_iteration (NULL, FALSE));" after setting the filename to avoid this problem, but this is a pretty horrible hack and I'm sure will cause me trouble in future.
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.