Re: notes from file selector talk



In this thread was discussed about the usage of tab expansion on the
dialog.

I just want to add that one of the most important abilities of the tab
expansion is to navigate through the directories... and not just
selecting a huge name or filter out some files.

For instance, you open your word processor.. and you want to open a
file.
The dialog promptly showed you what was at ~/ (for instance, just humour
me, please, any other place is just as fine).

Suppose, now, that the file is at
~/Documents/some/directory/in_a/not_so/short/path/file_with_a_really_long_name.st
h

Currently you can:
type:
Doc<tab>some/dir<tab>/in<tab>not<tab>s<tab>p<tab>file<tab>

which is much better than only being able to click on the folders.

If tab expands and moves focus to ok, the above will be lost.

Please be carefull to avoid that.

Now, one problem with tab expansion... the key tab. Usually that key us
used to change  widget focus, and that's important... it shouldn't be
lost.

However, what should be used in its place? Remember, we're talking
mostly of environments where tab expansion is not only common but also a
rather nice feature!!
Changing it to another character would bring overall inconsistency
(GNOME desktop with a behaviour inconsistent with the rest of the
system).

I think that the benefits of tab expansion PLUS the historical record of
tab expansion would suggest that best practice here would be:

...

  [ file name filed is last field                ]

            [ Cancel == Esc ]    [[ OK == Enter ]]

tab should stop at the file name entry, requiring shift+tab to go
upwards, and the two buttons below the entry can still be easily
accessed by Esc and Enter.

Cheers,

Attachment: pgpJIsdIdtj8u.pgp
Description: PGP signature



[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]