Re: First UI component needing replacement.

["Guillermo S. Romero / Familia Romero" <famrom idecnet com>]

kfox@vulpes.com (2000-08-13 at 1016.11 -0400):
> > http://www.thock.com/Dylan/new_dialog.jpg
> 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?

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

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

Note: I suppose the arrows may need to be translated for some
languajes. That or use up down (if that really does not cause problems
with any languaje, ctrl-up for previous dir, ctrl-down for complete).

>   <page down>  scroll the filename listing
>   <page up>

Yes. :]
 
>   <tab>        switch focus to the file type field

Logical with the rest of widgets. And shift-tab for back.

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

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

I see, but why give different meaning to keys based in mode? It will
cause problems with users, things must have only one meaning if
possible, not two. That read & match / write & do not match is a mess,
IMO.

For example, how do you overwrite a file then? Normally I type or
select, then hit any confirmations I am asked (Overwrite / Cancel).

> The filename text field should have the keyboard focus
> automatically too.

Of course. But you should be able to move to any widget with tab and
shift-tab.

> This key binding seems natural to me -- if you just type a
> pathname, it automatically does the right thing (and can give
> you filename listings and autocompletion at every step of the
> way). The keystrokes "../" will backup a directory level which
> is pretty common finger memory for Unix users.

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, machines must work for us, but do not try to behave as if they
were really smart. They are not at all, most times I had to use an
"auto" something, it failed, and if not most, too many times to be
acceptable. On the other hand, requesting fails less times, so few
that it is helpful in general (everyone I know loves shell completion
but few love auto-ortography, for example).

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

> The "built-in" file types can work differently. They might look
> for multiple glob patterns, MIME types or file content patterns.
> I'm just proposing extending that with user-defined filtering.

Yes.

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

Of course.

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

GSR