GNOME Bugzilla – Bug 308618
Make type ahead in file dialog specialized for filenames and paths
Last modified: 2005-06-27 16:35:33 UTC
In the file dialog you can use type ahead to select an entry in the file list. It would be nice if one could not only type in entries that are in the file list here but also other paths. For example if I type .. ENTER then it should jump to the parent dir even though there is no .. entry in the list. and if I type foo/bar it should jump directly to subdirectory foo/bar and if I type /tmp ENTER then it should jump to /tmp. I've been told that / currently opens the CTRL-L dialog but that just look bad to me since we now differentiate on relative paths like tmp (directory tmp in the current dir) and /tmp. These very similar operations now behave differently. Another enhancement is that this type ahead popup entry can support tab-completion. In a normal entry widget that's not good since the tab key is used to move the focus. But for a popup entry then using <esc> to close that is natural and <tab> can be use for completion. This whole thing changes the semantics of type ahead in the file dialog, but it's a proper superset. All the old functionality works the same and the added functionality makes the dialog a lot easier to use with the keyboard instead of the mouse. This enhancement request came after yet another long thread (on the gimp mailing list) about the new file dialog not being as easy to use with the keyboard as the old. With the above suggestion I think we can please all groups.
It would also be great if typing ~ or ~name followed by enter would go to the appropriate home directory. There doesn't seem to be any way to get to another user's home directory now aside from typing the full pathname; you can't go "up" from Home, and ~ doesn't work either.
The key thing is that it will no longer just be type ahead of the entries you see in the tree view, instead it will be type ahead of places where you can go in the file tree. That's why I called it specialized type ahead in the desciption. The good thing with the old gtk file dialog was the tab completion that made it fairly good for advanced users. With the above we get to eat the cake and have it as well. There is a drawback of course to change something known (type ahead) into something that look the same but really isn't the same. It can however still be used the same plus something more. I wrote this enhancement bug in hope that someone with enough free time like the idea and starts implementing. It almost never work like that, but there is always hope! :-)
*** This bug has been marked as a duplicate of 305385 ***