RE: First UI component needing replacement.

[Jorg Rathlev <jrathlev gmx net>]

> > 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.
>
> Space? And how do you insert a space? I would vote for ctrl-tab or
> ctrl-right_arrow. Shell users can live with "\ " for spaces, but I
> doubt GUI-only users will.
>
> >   <?>          filter file display looking for files that begin
> >                with what's currently in the filename field
>
> The same as above, I can type "\?" but will GUI users?

Here's another idea for autocomplete:

Autocomplete will be mostly be used when you're looking for a certain file
(uh, you knew that already?). If you've just typed "fo", you're probably not
looking for "bar.txt". So why should "bar.txt" be shown in the file list?

My suggestion is to hide from the list all files that do not match the
filename. Once only one match is left, autocomplete the filename to be that
of the only matching file (but leave the cursor at its current position and
select the completion proposal, so the user can overwrite it if it's not
what he wants - like in browsers).

So, for example, the list first shows:

  bar.txt
  foo_foo.txt
  foo_bar.txt

What you want to open is foo_bar.txt. So you start by typing "f". The list
reduces to:

  foo_foo.txt
  foo_bar.txt

where the f is highlighted in some way (bold? color?). Autocomplete
suggests:

  foo_
   ^^^

Where the ^^ is selected. <notsure>You press enter to accept the
autocomplete proposal (enter won't open any file yet since there is no such
file)</notsure>. You continue by typing "b":

  [list]
  foo_bar.txt

  [filename]
  foo_bar.txt
       ^^^^^^

You hit enter. The file opens.

Anyone with a better suggestion for the <notsure> part of my proposal?

> >   </>          interpret the filename field as a directory and
> >                cd there; clear the filename field after
>
> Clear? Not, if the guy types "foo/" before "bar.txt" (getting
> "foo/bar.txt"). Right way IMO would be change to foo, but keep the
> file name bar.txt. Data that can be kept, must be kept, not deleted.

Of course. This whole thing is a *great* idea, really.

> >   <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
>
> Do you mean foo.txt^H^H^H^H^H^H^H^H -> ../foo.txt ?
> Not pretty logic, IMO. I would vote for ctrl-left_arrow.

I'd say Ctrl+Up. You're moving *up* in the filesystem hierarchy, not left.

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

If there is no file that matches what you've typed, simply disable the Open
button.

> BTW, file completion should be requested not automatic, there is
> nothing worse than a computer trying to be stupidly obliging. How to
> explain it... I prefer a passive machine that a stupid active
> one.

Yes. That's why autocomplete should not move your cursor and select any
completion, so you can just type and overwrite it.

> > 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.)
>
> Yes.

I'd prefer the access to an advanced find file dialog (see below), which
will then allow the use of a "search script" (any application that returns a
list of files in some way).

> > 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.
>
> Sounds like Windows search. Works fine when you find the files you
> really want, but not quite good other cases, cos locks you in the
> results. This a field that needs lot of work. What happens if you get
> files and directories as result?

Why "locks you in the results"? Make "Search results" appear as a virtual
folder in the select foler box, so can easily jump back to another folder if
it's not what you wanted.


Jorg