GNOME Bugzilla – Bug 638528
Save As dialog makes too big an assumption when you enter the name of an existing directory
Last modified: 2018-04-15 00:06:51 UTC
This regression was not in 2.20 but it annoys me every day now. If the name you type into the filename entry is the name of an existing directory, the GtkFileChooser doesn't let the program decide how to handle this anymore. When you press enter and even when you click "save" it will change to this directory. Saving as "foo" doesn't always mean I want to save my file under a different name within the directory "foo" and in fact I've never used the GtkFileChooser that way. Moreover it is not always a mistake on my part. It is often the case that the filename you type in gets modified by the program using the GtkFileChooser before any saving is attempted. Specifically, the program will often append a file extension (Openoffice and Gimp are two programs that people have often configured this way). Steps to reproduce: * Find a directory named "foo" in Thunar or Nautilus or whatever. * Right click the directory and choose "create archive". * Depending on what archive manager gets called (Xarchiver here), a GtkFileChooser will appear with "append extension" checked and "tar.gz" already selected (the most convenient setting for my needs). * The filename entry will already contain the word "foo". * All that would be needed in Gtk-2.20 to create the archive "foo.tar.gz" containing the contents of "foo" would be pressing enter. * With Gtk-2.22, pressing enter changes to the directory "foo" and wrapping "foo" in the archive "foo.tar.gz" this way turns out to be impossible. Even if the convention of appending an extension is not "proper" it has been established for a long time and "intelligent directory changing" in the save as dialog has not. Please revert this feature or make it configurable or at least make it possible to programmatically disable it. So programs like Xarchiver can slowly update themselves to still work properly.
If the filename entry is showing "foo.tar.gz" and you hit Enter or Save, then *that* file should be used, regardless of whether there is a folder called "foo" and independent of what portion of the text is selected in the entry. For example, if the entry has [foo].tar.gz where [] are the selection bounds, then hitting Enter or pressing the Save button should cause that file to be used. If this is not happening, then we have a real bug. Is this your case? On the other hand, if you just have "foo" in the entry with no extension, then this won't work. Handling file formats and filename extensions is covered in bug #440431.
We don't have a real bug as you call it. Typing foo.tar.gz and selecting foo, indeed saves a file called foo.tar.gz without any problems. This is a case where I just have "foo" in the entry and the program is set up to assume that what I really meant was "foo.tar.gz". Having the program default to [foo].tar.gz where a callback on the filetype combo box changes the tar.gz to tar.bz2, zip, etc is probably a more elegant solution. I could patch Xarchiver to do this but first I wanted to let you know that this presumptuous behaviour in the file chooser causes real workflow interruption in programs that have non-ideal code related to handling filename extensions. If it were my decision (and I know next to nothing about maintaining a large project) I would leave the directory switching out of the Gtk2 filechooser and implement the switching and the unified file extension selector from bug #440431 at the same time in Gtk3. That way if applications want to make themselves compatible with the newest Gtk, it will more or less force them to correct the format selection code that conflicts with the auto-switching since there will be a standard widget for them anyway.
Dammit, xarchiver-0.5.3 came out after all these years and did not accept my patch to work with the file chooser.
We're moving to gitlab! As part of this move, we are moving bugs to NEEDINFO if they haven't seen activity in more than a year. If this issue is still important to you and still relevant with GTK+ 3.22 or master, please reopen it and we will migrate it to gitlab.
As announced a while ago, we are migrating to gitlab, and bugs that haven't seen activity in the last year or so will be not be migrated, but closed out in bugzilla. If this bug is still relevant to you, you can open a new issue describing the symptoms and how to reproduce it with gtk 3.22.x or master in gitlab: https://gitlab.gnome.org/GNOME/gtk/issues/new