GNOME Bugzilla – Bug 171709
.., ~ don't work in typeahead
Last modified: 2005-04-29 12:46:07 UTC
Version details: 2.6.4 Distribution/Version: FC3/i686 1. Open GtkFileChooser dialog in any app. 2a. Type ..<Enter> Instead of changing to parent directory, typeahead prompt just disappears. 2b. Type ~<Enter>, ~username<Enter>, or ~/bin<Enter> Instead of changing to specified directory, typeahead prompt just disappears. Old file selector doesn't respond to <Enter> either, but one can achieve the same effect with <Tab> (in fact, a much better effect as <Tab> also completes). Personally, I don't care if it's <Tab> or <Enter> but it should be possible to just type the directory name. Open Location subdialog can change directory and complete on <Tab> but to open it one has either to type Ctrl-L first (cumbersome) or type / and then delete it as one doesn't want to enter an absolute path (cumbersome). Obviously, a GtkFileSelector-like location prompt visible and focused by default would be the ideal solution, but since this is hardly going to happen, the current dialog should be made usable with keyboard at least.
I don't think we want ".." in the typeahead entry; you can hit Alt-Up for that already (and it is faster if you are navigating the file list with the arrow keys). For "~", I'm marking this as a duplicate. *** This bug has been marked as a duplicate of 153213 ***
Frankly, pressing Alt-Up is not an option. In which other file dialogs it works and who knows he can press Alt-Up? Why has one to think like like ,Oh, I'm in Gtk+ file dialog, so I can't type file name normally, but relax, there's some secret method to get into parent directory, only if I remembered what it was...`. When one gets a file open dialog, one can simply type a file or directory name. A dialog that prevents that is broken from usability viewpoint. If Gtk+ file dialogs can't have the usual file name entry, and have to support this basic functionality via two independent half-hackish mechanisms instead (additional prompt minidialog, typeahead), then let it be so. But please at least support it properly. But this is a waste of time as you've probable been told this a zilion times so I suppose your goal really is to make everyone to implement his own -- incompatible and buggy -- file dialog.
That may in fact be the way to go the next time we thing about redoing one of our common dialogs in a better way. The file chooser has certainly given us nothing but hate and flame, before the redesign and after