GNOME Bugzilla – Bug 307378
inconvenience API gtk_file_chooser_set_filename()
Last modified: 2005-06-13 21:21:22 UTC
Distribution/Version: cross platform Beside requiring an absolute filename - see bug #133463 - which also must exist gtk_file_chooser_set_filename() imposes a race condition on application developers. With the sequence gtk_file_chooser_set_filename (GTK_FILE_CHOOSER(exportdlg), "/tmp/file.a"); gtk_file_chooser_set_current_name (GTK_FILE_CHOOSER(exportdlg), "file.b"); one ends up with "file.a" in the exports dialog entry. Obviously "file.b" was intended and given the comment in bug #305850 this even worked with gtk+-2-4. The workaround is to split dirname and basename and use gtk_file_chooser_set_current_folder() and gtk_file_chooser_set_current_name() - as I said inconvenient. Obviously the inner working of FileChooser needs to split the path as well;) BTW: the use case is an export dialog which remembers the last used export format and adapts the file extension to that. See: http://cvs.gnome.org/viewcvs/dia/app/filedlg.c
set_filename() is meant for selecting an existing file, and is documented as such. I don't really understand the race condition that you are referring to ... if that sequence actually gives you file.a, that's a bug not an API issue. If you have a "filename" of a non-existing file (as a full path) then note an encoding issue: gtk_file_chooser_set_current_folder() expects a filename encoding string, while gtk_file_chooser_set_current_name() expects a UTF-8 encoded string. set_current_name() is *as if the user typed it*. GtkFileChooser never makes any interpreation of filenames or assumes they can be manipulated as strings, it leaves that all to the particular backend, and the API is designed to facilitate that by always only using filenames to refer to actual existing files.
Created attachment 47649 [details] a simple test program Yes it gives file.a as the attached program shows - if you run it with an exisiting *absolute* filename. As application developer I'm not that interested in the inner workings of GtkFileChooser and given your description I seem to be particular bad at guessing the right encoding. I still think there should be something more friendly for the described use case - especially when the application developer is forced to use two different encodings to just correctly set the export filename suggestion. So this is done wrong: http://cvs.gnome.org/viewcvs/dia/app/filedlg.c?r1=1.52&r2=1.53
*** This bug has been marked as a duplicate of 302087 ***