The gtk file selector once again

[Allin Cottrell <cottrell wfu edu>]

I realize that the issue of the GTK file selector has probably been
done to death in previous discussions; nonetheless I'm foolhardy
enought to want to throw in my two cents' worth.

I don't have a problem with the appearance of the file selector in gtk
2.0 -- I'm not looking for snazz in a file selector and the current
one seems quite well designed.  My problem is with the question of
completion versus globbing.

Let's try to imagine designing a GUI file selector from scratch,
starting from the background of file selection at the shell prompt (I
make this suggestion since it seems clear that the completion
mechanism in the gtk file selector was inspired by shell usage -- it
certainly didn't arise by way of emulation of any other GUI file
selector).

When I'm selecting a *plain file* at the shell prompt I often find
myself using a combination of globbing and completion.  Say I'm
looking for a particular TeX source file but I can't remember exactly
what it's called.  I'll likely start with "ls *.tex" (using globbing
to filter the file listing); I'll spot the file I want, say
"this_has_a_long_name.tex"; and I'll grab its name with "thi<Tab>"
(completion).

When I want to cd to a particular *directory* I'm more likely to use
completion without prior globbing.  Directories are far fewer than
files and I may well know the name of the directory I want.  E.g,
knowing that my mozilla installation lives in /opt/mozilla I can get
there with "cd /opt/mo<Tab>".

Now the GUI selector.  It seems it would be nice to have some
counterpart to both globbing and completion at the shell prompt.  It
may be possible to have both, but first let's think: Which of these
facilities should have higher priority?  (I leave aside for the moment
the issue of what users will *expect* to find, based on experience
with other GUI file selectors.)

It seems to me fairly clear that providing a globbing facility should
have higher priority.  Consider the cases of plain files and
directories in turn.

Plain files.  I'm looking for that particular tex file again.  If the
selector can run a glob filter for me, I'll see the file I want right
away and I can select it with a simple double-click.  Completion might
be nice to have but compared to the shell prompt case it's relatively
redundant.  It's true I could have used the mouse to get
this_has_a_long_name.tex at the shell prompt, but manipulating the
X-selection is inherently more awkward than double-clicking on a
filename, and doing so involves switching from "keyboard mode" to
"mouse mode".  In the GUI file selector I'm probably in mouse mode
already, having invoked the file selection dialog by clicking a button
or selecting a menu item.  Thus the completion mechanism that I value
at the shell prompt is much less likely to be used in the GUI file
selector (even if I know that it's available).  On the other hand, if
the current directory contains many files of mixed type I'm really
going to miss globbing if it's not available.  Needle in haystack.
I've been there often with the gtk file selector.  I want to see
*.tex, not thi*.

Directories.  Completion is nice to have in this case.  In the gtk
file selector I can quickly jump to an unrelated directory via
completion. E.g. if I'm in /home/me/subdir I can get a listing of
/boot with just "/bo<Enter>".  But a couple of factors make this
advantage relatively unimportant, IMO.  First, with a well designed
program there's not likely to be much call for jumping around between
directories: the file selector should open pointing to the directory
that is likely to be wanted.  Second, there are other good (and more
familiar) ways of changing directories available, via the left pane
directory listing and the drop-down directory hierarchy.

I guess one could have both globbing and completion.  It might get a
bit confusing, but the "selected file" entry could use completion as
at present while a new "filter" entry could added, using globbing to
limit the right-pane file listing.  If it's a choice between the two
mechanisms, though, I'd say that globbing ought to win.  I've argued
this from "first principles".  The other (weighty) consideration, of
course, is that the great majority of users will expect to find a glob
filter in a file selection dialog but will not expect auto-completion.
How many people actually use gtk completion?  I really only figured it
out properly after reading gtkfilesel.c!

Allin Cottrell