Usability of gnome file chooser when saving file to new folder

[Jochen Schmitt]

Before Ubuntu 8.10, if you wanted to save a file in a new folder, behavior was like that:
Press ctrl+s ("save as") in an application like gedit. Gnome file chooser opens, press "Create Folder", enter folder name, press return. New folder was already selected, by pressing two times return you could save your file.
In 8.10 the new folder is not selected any more, you have to double click on it and then press save. This is especially annoying if you are in a directory with many folders - then you first have to scroll down to find the folder you just created.
I tested this with several applications (firefox, gedit) and an up-to-date Ubuntu 8.10 (AMD64).

[Arnaud Soyez (weboide)]

Confirmed in 8.10

The folder takes a while to get created and (so?) it loses focus. Pushing Enter at this point will hit the Save as button (instead of entering the newly created directory)

[Jochen Schmitt (schneemagic)]

changed package to gtk+2.0

[Altieres Rohr (altieres)]

"New folder was already selected, by pressing two times return you could save your file."
If I remember correctly, only one "enter" was needed after it was named, because you were already put inside the folder. Just leaving focus on the new folder is the way Nautilus does it. On file chooser, the process was thus:

1. Click the button to create a new folder
2. Gnome File Chooser asks for the folder's name. Input it and press Enter to confirm
3. Press Enter or click Save

Now it's like this:

1. Click the button to create a new folder.
2. Gnome File Chooser asks the folder's name. Input it and press Enter to confirm
3. After some delay, the new folder is put on the folder list along others. It has no focus.
4. Double-click the new folder to be put inside it
5. Press Enter or click Save

So step 3 didn't exist because step 4 was automatic. Such was Gnome's File Chooser behavior before 8.10. CentOS 5.1 (which uses an older version of Gnome), Windows and (I've heard) MacOS X do it like this as well. It seems to me Qt/KDE does it different, though I can't confirm it.

[Alexey Nedilko (alexey.nedilko)]

Dear maintainers,

Do you lack any information about this bug? It's 100% reproducible (at least on my environment) so you can ask for any detail you need...

I consider this bug to be a regression one, 'cause it's not reproducible in Ubuntu 8.04 (GNOME 2.22)

BTW, is is already reported upstream? I've searched the GNOME Bugzilla, but haven't find it...

In general, could you please leave any feedback here? The bug is rather annoying, and I don't believe it's hard to fix. [b]Any[/b] feedback would be highly appreciated. I'm not a GTK+ developer, but I'm eager to spend some time on tracking this issue down, if I'm given at least some traces where to search for it roots :)

[Sebastien Bacher (seb128)]

the bug has not been sent upstream no and there is just lot of bugs and not enough bug triagers so it can take time, you can send the bug to GNOME though

[Pedro Villavicencio (pedro)]

I've sent this upstream at: http://bugzilla.gnome.org/show_bug.cgi?id=564307 ; thanks.

[Siafu Linux (siafulinux)]

I can confirm this on my Ibex system as well.

[Chris Schoonbee (cmschoonbee)]

The correct (original) upstream bug to watch appears to be at:
http://bugzilla.gnome.org/show_bug.cgi?id=552619

I hope it gets fixed - I find it a highly annoying and unnecessary regression.

[Milan Bouchet-Valat (nalimilan)]

I've posted a patch upstream, the problem was very simple, coming from a typo in if() condition. Maybe it will get into next GTK+ release.

[Pedro Villavicencio (pedro)]

it was fixed upstream, thanks for reporting and your work on it.

[Sebastien Bacher (seb128)]

the new version is in jaunty now