Re: First UI component needing replacement.

[colin z robertson <c z robertson ndirect co uk>]

On Sun, Aug 13, 2000 at 06:17:50PM -0400, Ken Fox wrote:
> How many file names have you seen with "?" in the name? Or space
> for that matter?
> 
> Perhaps this is a matter of choice, but I'd prefer to not use
> either of those characters in my file names if they made entering
> file names easier.

There are 226 files with space in the name (or path) on my system.
(locate " " | wc). And, while I have done so in the past, these days I
don't put spaces in filenames if I can help it. The problem with
files, though, is that they come from all sorts of different places.
You only create a small fraction of the files that you have on your
system, and many of the files that you get will be from Windows users,
who have no qualms about putting a space in the filename.

I'm not actually sure that a special character is needed for
auto-completion, certainly not in Open mode. Consider how Netscape 4
handles auto-completion in the url bar: the auto-completed section
after what has been typed is selected, so when the user hits the next
character it is replaced and then updated again. Whether we want a
open/save dialog box to work like this is another matter... I'm not
quite sure about it myself.


> > >   <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

I can't agree with this. If I want to clear an entire text box I often
hold down the backspace key until I see that everything has gone.
Other users might repeatedly press backspace very fast to achieve the
same effect. Either way it would result in backspacing past the
beginning of the text field resulting in some unintended directory
jumps.

Also the idea of tying this to the history rather than to the
directory hierarchy seems highly unintuitable.


> > >   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
> > 
> > Users will think that keyboard is dirty or app broken.
> 
> Why? The system beeps and displays a little popup-tip window over
> the text field that says "no such file". You don't want people
> typing in non-existant file names when the dialog is asking for
> a file to read.

What happens if the user is editing the middle, rather than the end,
of a filename? "food.txt" is already in the text field, say, and the
user wants "foolish.txt", so the user deletes the "d" and types
"lish". I'm not sure what the correct behaviour in that situation is.
Certainly it is not to restrict what gets typed on a character by
character basis.

Another problem with this restriction is that users won't be expecting
it. The user wants "foobar" (which exists) but instead types "foobat"
(which doesn't), quickly realises his mistake and hits backspace and
then "r" without looking at what's on the screen. The result is
"foobr" if it exists or "foob" if it doesn't.

colin

  _____________________________                            ____
  rtnl  http://rational.cjb.net     c.z.robertson@ndirect.co.uk
  ak    http://kitching.cjb.net                    icq 13294163