GNOME Bugzilla – Bug 167188
Answering "No" to the replace file prompt closes the save dialog
Last modified: 2008-07-27 14:53:42 UTC
To reproduce: 1. Make a screenshot 2. Enter the name of a file that already exists 3. Click on "Save" You will get a "File already exists, do you want to replace it?" dialog. 4. Click on "Cancel" The save dialog disappears, the screenshot is not saved and is now lost forever. Expected result: the save dialog would remain and let me enter a different file name. Other information:
The "File exists" dialog is not provided by gtk (at least not yet), thus this is not a gtk bug.
Ah. I experienced the same problem in Firefox, which uses the Gtk+ save dialog in recent Ubuntu Hoary, so I assumed it was Gtk+'s fault.
It's in gnome-utils now.
I was about to file this too, since it has bitten me today. Here is a patch which fixes it... I was hoping for something simple, but when vfs_xfer is involved...
Created attachment 48717 [details] [review] patch The patch introduces a callback function that it is passed to screenshot_xfer and called when the xfer is done. In the callback we check if the xfer was successful and set a "success" variable accordingly (it sucks that's a global var, but the code is already using those...). In the dialog look we check for success and if we are done we exit otherwise the dialog continues to run. The first hunk of the patch is a small mem-leak, which becomes more significative since we are not always exiting like before
Still an issue. This patch should go for GNOME 2.14
Created attachment 56351 [details] [review] Proposed patch This smaller patch worked for me.
*** Bug 339454 has been marked as a duplicate of this bug. ***
Created attachment 64148 [details] [review] Another patch that changes the behaviour This patch changes the behavior so that when you click on Cancel in that dialog: - The dialog is being dismissed - You are being returned to the main gnome-screenshot dialog - The GtkEntry with the filename is being focused again - The "name" part of the filename is being selected again so you can choose another filename The technically correct solution woud be probably to hook up to the 'duplicate' hook and pop up another dialog there that asks for a different URI/filename, just that sound somewhat slightly annoying. This patch is made against gnome-utils HEAD as of Apr. 23rd 2006
The previous patches are smaller and less intrusive than mine, but i'd vote mine for better usability really: When you click on "Cancel", you can immediately return to go back to typing in a new filename. That sounds perhaps like a minor thing, but in practice this WILL matter (i actually tried the other patches and found it quite annoying that i have to click or use an accel to get back to the entry to type in another filename, plus i'd have to select the name-without-suffix part of the filename myself).
That's still happening with GNOME 2.17.91, Ubuntu bug about that: https://launchpad.net/gnome-utils/+bug/85821 Could any maintainer review the patches and maybe apply one of them before GNOME 2.18?
*** Bug 470162 has been marked as a duplicate of this bug. ***
*** Bug 526449 has been marked as a duplicate of this bug. ***
Looks fixed in trunk.