GNOME Bugzilla – Bug 158423
Confirming the Location dialog should accept the file chooser and close it
Last modified: 2006-10-19 15:50:46 UTC
there are a few issues listed here, because they're fairly trivial, and they may not be GIMP specific but general GTK issues, i'm afraid that i've only got GIMP installed to test with at the moment. Ctrl+L can be used to display the "Save in location" dialog as many times as you like until you press the cancel button in that dialog and then cancel the save dialog too. now, if you attempt to save the image again, Ctrl+L will no longer work. this only affects save dialogs from the originating image window each time it occurs. similar issue with Opening files, though it disables Ctrl+L for any open file dialog opened from any window including the toolbox. also, the caption text used for the confirmation button in the Save/Open in location dialog is misleading, clicking save when a filename has been entered doesn't actually save the file, but returns the user to the save dialog with the new path and filename filled in. another miniscule bug occurs when creating new directories, the icon used for the new directory during initial text entry is that of the file that was previously at the top of the directory listing.
You should try to avoid reporting multiple problems in a single bug report and you should have definitely searched for duplicates first. At least one of these issues has been reported before (and fixed). Reassigning to GTK+ so that the GTK+ developers can deal with this.
The first two issues are described in a comment to bug #145470. I just fixed the fourth issue; it was a silly bug. I'll retitle this bug and leave the third issue open: Have the Location dialog confirm the entire file chooser if you accept what you typed.
IMHO this should only be done if what you type actually was an existing filename. At least I was using the location dialog to quickly change the directory - not knowing the concrete filename.
Created attachment 46870 [details] [review] patch to implement the suggested behaviour The should_respond() handler already takes care of deciding if the dialog is in a state that can be safely activated so this patch is rather simple. It duplicates some code from gtkfilechooserdialog.c though. This could be avoided by adding an internal API to activate the confirmative action of the file-chooser dialog.
Comment on attachment 46870 [details] [review] patch to implement the suggested behaviour Thanks for the patch, Sven! Instead of doing all the default response stuff, can't you just emit ::file_activated if the user confirms the location dialog? This will get caught by GtkFileChooserDialog, which will in turn call should_respond() - which should already pick up the changes done to the file chooser's state in update_from_entry().
Created attachment 46898 [details] [review] patch changed as suggested (includes debugging statements!) Sounds like a good plan but unfortunately it doesn't seem to work. I've changed my patch and added some debugging output. As you can see, gtk_window_activate_default() is being called on the dialog but it doesn't have the desired effect.
Created attachment 46899 [details] [review] complete version of previous patch sorry, the previously attached patch is incomplete
*** Bug 308917 has been marked as a duplicate of this bug. ***
*** Bug 315523 has been marked as a duplicate of this bug. ***
*** Bug 324995 has been marked as a duplicate of this bug. ***
(In reply to comment #3) > IMHO this should only be done if what you type actually was an > existing filename. At least I was using the location dialog > to quickly change the directory - not knowing the concrete > filename. yes , I think there is a great danger of retrograding usablility if you try to preempt what the user is doing. This one area where Windows falls down , it always thinks it knows what you want to do ... and often gets it wrong. An interface needs to be consistant in how it behaves otherwise it is confusing. It is a basic principal of interface design to avoid modes of behaviour. ie different response to that same action in different contexts. In this context an open dlg and a save dlg are two different things to the user (even if there is a common code base) so it is ligitimate to have different behaviour - within reason. Different modes of behaviour within the same dlg really should be avoided. regards.
I was about to report this issue, but see that it is already well known. Let me add a 'me too'. Particularly annoying: You know from bitter experience that populating /usr/bin takes a while, so you type <ctrl+l>/usr/bin/acroread instead. Lightning fast, because of the excellent completion. Then you confirm - the button even says "open". And you have to wait for the file list to be populated before you get the chance to "open" once more. One final compliment: Populating /usr/bin is a lot faster these days :-)
Hmm. Tried HEAD and Ubuntu Edgy, and it looks like this is fixed. Can the bug be closed?
Yes. There is no location dialog anymore in GTK+ 2.10.