Re: First UI component needing replacement.

[Ken Fox <kfox vulpes com>]

Dylan Griffiths wrote:
> http://www.thock.com/Dylan/new_dialog.jpg

I haven't seen anybody comment on how the keyboard interface
would work, but I'd like to propose it do something like emacs.

In the filename text field, use these key bindings:

  <space>      auto-complete as much as possible using what's
               currently in the filename field as the prefix.
               letter case isn't used to auto-complete unless
               an option with both upper and lower case exist.

  <?>          filter file display looking for files that begin
               with what's currently in the filename field

  </>          interpret the filename field as a directory and
               cd there; clear the filename field after

  <backspace>  if the filename field is empty and there is a
               directory history (i.e. "/" was used to cd) then
               switch back to the previous directory and restore
               the old filename field contents
               
               otherwise, just delete the character left of mark

  <page down>  scroll the filename listing
  <page up>

  <tab>        switch focus to the file type field

  Anything else just inserts into the filename field at the mark.
  If the dialog is in "read file" mode, it doesn't allow you to
  type letters that don't match a file. (Note that the behavior
  of <space> works fine to select files with spaces in the name.)
  If the dialog is in "write file" mode then any character that
  doesn't match an existing file is just inserted at the mark.
  This includes <space> and <?> but not </>.

The filename text field should have the keyboard focus
automatically too.

This key binding seems natural to me -- if you just type a
pathname, it automatically does the right thing (and can give
you filename listings and autocompletion at every step of the
way). The keystrokes "../" will backup a directory level which
is pretty common finger memory for Unix users.

I'd also like the file type field to allow keyboard input. Any
input to this field should be a file globbing pattern that's
incrementally applied -- as soon as a character is typed the file
list is filtered. If the user hasn't typed a wildcard, a trailing
* should be assumed. Filters should be remembered between
sessions and appear in the drop-down filter list. (There should
also be hooks for advanced users to put in a hunk of extension
language code (Guile, Perl, etc.) to make advanced filters.)

The "built-in" file types can work differently. They might look
for multiple glob patterns, MIME types or file content patterns.
I'm just proposing extending that with user-defined filtering.

I'd also like to see a URL browsing option so that ftp and http
servers can be browsed similar to local file systems. (This could
be an "advanced" option on the dialog that appears when a "more"
button is clicked.)

Finally, the open file dialog *must* allow easy access to an
advanced find file dialog. This could either be a separate tab
in the dialog or on the "more" section. The find options must
allow filtering by creation/modification times, file types,
file names, owner and location. Treating the results of the
find as a virtual filesystem seems very natural to me -- once
the find finishes, just drop the user into the standard open
dialog with the list/tree hooked up to the find results instead
of the underlying filesystem.

- Ken