Re: First UI component needing replacement.

[Ken Fox <kfox vulpes com>]

[BTW, please don't use *my* weird ideas to disparage emacs. I
 said emacs-like, but then I went off in different directions
 from what emacs actually does. Emacs has a nice file selector
 keyboard interface. It breaks down a bit on the graphics
 display side though. Anyways, the editor wars have enough
 victims already and I don't want to throw my body on the pile.]

A lot of the points raised here are addressed in my last note.

Dylan Griffiths wrote:
> Ken Fox wrote:
> >   <?>          filter file display looking for files that begin
> >                with what's currently in the filename field
> 
> Entry of regular expressions would very much be a feature I'd like to
> incorporate, besides simple mime type filtering.

I'm not talking about entering a file pattern here. The <?> is a
command that asks the file dialog to refresh the file list with only
the files that are interesting to me. The highlighting of files can
happen automatically, but removing files from the display should be
a user requested command.

> For the system filemanager, though, we'd want to ensure that the user could
> select a group of files with nothing whatsoever in common easily

I don't want to see a crippled file dialog just because the functionality
appears in the file manager. We should put all the commands necessary
to find and select a file into the file dialog.

> http://www.acm.org/cacm/AUG96/antimac.htm

Excellent article.

> >   </>          interpret the filename field as a directory and
> >                cd there; clear the filename field after
> 
> Better still, if the filename is NOT a dir that exists, do not clear it.
> There's no need to punish a user for a typo.

Yeah, I agree. It shouldn't be possible to type in a non-existant
directory when opening a file for read though.

> >   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 </>.
> 
> There you go, giving multiple meanings to different keys based on the
> context.

There I go. ;) The computer has such a pathetic low bandwidth user
interface that it's almost impossible to avoid context-specific
interpretation of keystrokes. You already said that <space> can scroll,
or activate a button or cause " " to be inserted in a text field.

If you look at the mental state of a someone using a file dialog they
are going to be in one of two modes: (1) looking for a file to open
or (2) looking for some place safe to save data. If hitting <space>
fails to auto-complete it can either beep or insert the space
depending upon which conceptual mode the user is in. That's not a
significant problem. Understanding and recovery is fast in either
case, so why not choose the most useful possible error mode?

> "average" computer user defined as someone who just uses it for 
> web/email/etc).  For reasons of consistency, I prefer to keep the
> dialog shortcuts functioning in one way only.

You quoted the anti-mac article and now you slavishly appeal to
the mac status quo?

Your average user probably doesn't know how to type either so why
would you design a keyboard interface for him?

> > 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.)
> 
> That would be the purpose of the File Name field accepting regular
> expressions.  The MIME type field is to filter MIME types only, and allows
> programs such as Netscape to say, "I just want to show HTML files right
> now."  I'd prefer if there was a way to specify several MIME types to filter
> in or out cleanly, but I'm not sure how to expand beyond a "All
> Types/Specific MIME type" pulldown box.

I don't want to enter patterns in the file name field. That's
confusing because if the file name is a pattern what gets sent to
the application when I press the OK button?

The file type can certainly support sophisticated MIME types and user
defined file patterns. In fact, the line should be very blurry so that
users can extend simple file patterns with (Scheme, Perl, etc.) code
to make them into advanced types.

> > 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.)
> 
> No No No No No No No No No :)
>
> FTP is very different from a proper file system.  Integration of such code
> is messy.  Have you ever tried to use anything beyond browsing into
> compressed files in Midnight Commander?  HTTP itself is so stateless as to
> be useless beyond simple browsing.
> 
> I can see supporting compressed files as slow directories, but not HTTP and
> FTP.  If you want file sharing, enable Samba, NFS, Coda, or one of the other
> *proper* filesystems which would not clutter the interface and code.

Conceptually it makes sense to use the same file dialog for anything
which resembles a file system. I'd like to know in what respects you
think FTP is different from a local file system. Performance? In that
case you must want a different browser for floppy disks. ;)

If the implementation is busted then we should fix that instead of forcing
different user interfaces for the same "find a file to open" user task.

I've not used mc, but I have used other virtual file interfaces. (One of
which I built in perl so I know performance isn't a big problem.)

> That Would Be Bad :)

In what ways? If the user interface isn't complicated by these advanced
features I can't see any way that this is Bad. We're talking about a
shared library which is probably already memory resident -- no code bloat
to worry about. We're talking about an interface that brings the browsing
to the application instead of forcing somebody to jump to a different
application and back again. The growth pattern from point-and-click to
keyboard usage is simple.

- Ken