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 133463 - gtk_file_chooser_set_current_folder should accept non-absolute filename
gtk_file_chooser_set_current_folder should accept non-absolute filename
Status: RESOLVED WONTFIX
Product: gtk+
Classification: Platform
Component: Widget: GtkFileChooser
2.3.x
Other Linux
: Normal normal
: Small API
Assigned To: gtk-bugs
Federico Mena Quintero
Depends on:
Blocks:
 
 
Reported: 2004-02-05 04:45 UTC by Andreas J. Guelzow
Modified: 2006-04-13 02:06 UTC
See Also:
GNOME target: ---
GNOME version: 2.9/2.10



Description Andreas J. Guelzow 2004-02-05 04:45:44 UTC
gtk_file_chooser_set_current_folder (file_chooser, ".");

segfaults (assuming a valid file_chooser)

Similarly:

gtk_file_chooser_set_filename (file_chooser, "output-here.pdf");

segfaults
Comment 1 Owen Taylor 2004-02-05 14:51:53 UTC
Think this is a duplicate of something already fixed in CVS.

*** This bug has been marked as a duplicate of 132693 ***
Comment 2 Andreas J. Guelzow 2004-02-05 16:40:24 UTC
It's a pretty big stretch of the imgination to call this fixed:

Apparently the fix consists of an assertion to require an absolute
pathname. It does not fix the segmentation fault itself.

THere is really no excuse for the GtkFileChooser to try to offload the
handling of relative path names to the calling application.

Moreover, if we pass a complete pathname the complete path name
appears in the entry box, which is highly undesirable. 
Comment 3 Andreas J. Guelzow 2004-02-05 16:54:37 UTC
Sorry, I was mistaken
...current_name inserts the whole path,  ...set_filename strips the
path but does not insert the basename if the file doesn't exist. 

SO I guess we are expected to:
1) turn the filename from utf8 into filename encoding
2) if it's an absolute path call set_filename otherwise construct an
absolute path and then call set_filename.
3) extract the basename from the path
4) convert the basename back to utf8
5) use current_name

I don't think this api is well thought out.
Comment 4 Morten Welinder 2004-02-24 00:46:51 UTC
The use of g_path_is_absolute implies that the file name is fs encoded,
not UTF-8 encoding.

If gtk_file_chooser_set_filename expects a UTF-8 encoded name (or if
it does not agree with itself on that it expects) then that is a serious
issue.

I can live with an absolute filename being needed, but I do not think
it is very elegant, nor is it necessary.
Comment 5 Morten Welinder 2004-03-10 14:37:07 UTC
I'm pretty confident that we do not have encoding problems with
filenames, i.e., that they are all fs encoded as they should be.
Lowering priority.  Retitling.
Comment 6 Federico Mena Quintero 2006-04-13 02:06:56 UTC
I'll mark this as WONTFIX.  Here is the rationale:

1. Using gtk_file_chooser_set_current_folder (chooser, ".") would mean that the chooser would appear in $cwd.  Most of the time, that will be the user's home directory, since that is the $cwd for applications launched through the panel's menus and other desktop launchers.  $cwd is not very interesting:

1.1. Currently, a file chooser will appear showing $cwd if gtk_file_chooser_set_current_folder() has not been called.

1.2. Even if $cwd were something other than $HOME in the common case, it would still not be the most useful folder for the user to get in the file chooser.  The most useful folder is one of the folders which the user has accessed most recently.  In GTK+ HEAD we are doing work to add recent-files support to the file chooser.

2. Calling gtk_file_chooser_set_filename (chooser, "foo.txt") means that you already know that there is a foo.txt in $cwd, so you may as well pass the complete pathname.  Otherwise, you are probably getting confused with gtk_file_chooser_set_current_name(), which you use to suggest a filename for SAVE mode.