![[ alex ]](http://mesozoic.geecs.org/static/images/alex-icon.png){kind=icon}
I just saw some mockups on Planet GNOME of the new and improved GNOME file chooser. Seth Nickell has posted some additional screenshots, and I really like the way it looks. But while I think it’s a vast improvement, there’s one very minor detail that will seriously affect GNOME usability in the hands of the average user: the text field is missing from the “Open” dialog.
Seth explains that in order to get a text field to type in, one must first press Ctrl-L. He comments that:
No entry widget means list selection is a direct manipulation, rather than going through a layer of abstraction. Conceptual model is “List selection chooses items to open” vs. “List selection changes the entry widget, the entry widget indicates the file name to open from the current path”.
Well, that’s just silly. The entry widget is not some obscure feature that most people don’t need; this is something everyone expects to be present in an “Open” dialog box. While there’s justification for changing the way the entry field works (perhaps turning it into a filter) there’s no real benefit gained by removing the text field from the dialog entirely, even if it’s still accessible with a hotkey.
Let me interject that having a keyboard shortcut is nice, because Ctrl-L is the standard shortcut for the address bar in Nautilus, Mozilla, and other applications. But the way those applications work is that Ctrl-L simply moves focus to a text field that is already there. Instead, in this design, one of the most basic elements of an “Open” dialog box — a place to just type what you want — is hidden from the default view. This will frustrate some users, and for no good reason.
I like keyboard shortcuts. I’ll probably use Ctrl-L in the new GNOME file dialogs a lot. But many people don’t like keyboard shortcuts, and they shouldn’t be penalized for it. I hope someone on the GNOME team feels the same way, or this unnecessarily confusing “feature” will wind up detracting from the overall interface.
![[ Firefox ]](/static/images/firefox_80x15.png){kind=small}
![[ Hacker ]](/static/images/hacker.png)
>because Ctrl-L is the standard shortcut for the address bar in >Nautilus, Mozilla, and other applications. But the way those >applications work is that Ctrl-L simply moves focus to a text field >that is already there.
if you start nautilus in spatial mode (just “nautilus”, not “nautilus –browser”), then it also doesn’t have a text-field. and if you press Ctrl-L, it opens a little window with a text field for you.
(in gnome-2.5.*)
I wasn’t aware of that. I’ve been using GNOME 2.4 (Nautilus 2.4.1), and I like having an address bar readily available. Again, I don’t see any reasonable argument for obfuscating such a basic element of the user interface.
If you’re using a GUI for some task, what’s
wrong with clicking? You’re probably already
tightly gripping the mouse.
If you want to type, use a text interface (xemacs
comes to mind; if you use the shotcut (C-x C-f),
you’ll get to type the filename (with tab-completion, etc.) into the minibuffer. If, instead, you use your mouse to poke file | open,
you’ll get a dialog…
Well, you know, I for one think that it doesn’t actually matter if you *display* the text box as long as it still works. If I were designing the open dialog, you’d see a listing of the files in your current directory. Then you could type letters to scroll to a file or point and click, and if you hit tab and slash, you could have moved to a sub-dir. That’s what I’d want to do with it anyways.. a combination of typing and viewing the files in the dirs; my keystrokes could be the same as what I type when specifying a file in bash (with the possible exception of editing commands like control-u or the arrow keys).
That being said, I have not actually viewed the dialog box in question. But I do find the lack of feedback from the text-boxes in some unix open dialogs annoying.