file selection in 1.3/1.4

[John Richardson <jrichard zealand mv com>]

(I don't think I posted this to the list twice, but I may have)

> > Hi!
> > During the development of gtl+-1.2 I sent in a patch that allows the use
> > of filters for the file selection dialog (so that you may opt to show
> > only *.gif and *.bmp for example). Sadly enough it was a bit too late
> > and did not make it into 1.2. It would be nice to see it in 1.4 (I would
> > send in an updated patch of course, if needed)
> >
> > Another thing for the file selection dialog is: At the present time
> > files starting with . like .xinitrc or directories like .enlightenment
> > are not shown in the lists. This is useful most of the time, but
> > annoying sometimes. A flag controlling this behaviour would be great,
> > too.

Even better, a checkbox somewhere on the dialog itself.  Here's my critique
of the current file dialog:

Layout:
      the first thing the user sees is the "Create Dir" button (eyes usually
start
        at the upper left and move right spiraling inward, or move left to right
from
        the top).  Since these buttons at the top are relatively unused, they
should
        be lower somewhere.   This is a matter of taste I suppose, but I think
the
        create/etc buttons should live on the right side of the dialog, as
unobtrusive
        as possible.

File Filter:
     I like the idea of the directory being an pulldown menu (better than motif)
as
        is implemented in gtk already, but that leaves no place for a file
        filter.  Perhaps, as someone suggested, that
        should be in the "selection" text field, but then it might be hard to
type in
        files with glob wildcards in their name.  In any case, there would also
need
        to be some visual display of what filter is in use currently.

File/Dir view:
     I like the idea of combing the files and directories (a la win32).  They
could be
        distinguished by a different font, color, or icon.  (Again, I think the
icon is
        something else windows did right).  This maximizes the usable space if
        there aren't enough of either files or directories to fill a block.  It
also allows
        for a more (ls -l) like listing for knowledgeable folks.  I realize this
could look
        like a microsoftism, but please look at it for it's value, not who
copied it last.


> I think it's about time for a new file selector.  The current one is not
> very good I don't think.

The current one is OK, but a little clumsy.

> If I go crazy enough using this one I may take a stab at rewriting it.
> Anyone think of any good design ideas ?
>
> I had a thought, and I don't know if it's a good idea or not, but you could
> keep a history and/or bookmarks for the file selector, possibly saving state
> in a user dotfile.

Keeping this information would be a VERY good idea.  My experience has been
that most new users don't have a good idea of a directory structure.  They need
some simple way of describing where they are placing their files that doesn't
rely
on remembering what the full directory path was in a popup (a la windows file
dialog) but have a hard time understanding how to move about when they
only see text (a la Motif fileselectiondialog).

Bookmarks with nameable titles would be perfect here.  Ideally, there would be
some mechanism that users could register a bookmark area.  Applications
could use this to create a default storage area for you for your app (so newbes
won't
loose files as easily).

Power users should be able to ignore the bookmarks though.  They will be
useful, but they shouldn't be the /only/ system.


John