Re: File dialogs: an attempt at a summary

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

On Thu, Aug 17, 2000 at 02:00:16PM +0200, Christian Rose wrote:
> colin z robertson wrote:
> > > If so, it wouldn't be too hard to change "Open" to "Add selected" and
> > > "Cancel" to "Done" .. the difference would be that the dialog would build a
> > > list of files in the format:
> > >
> > > "/usr/bin/file1"; "/home/user/file2"; "/home/user2/file3"
> > 
> > But doesn't this break the <ctrl>+<click> and <shift>+<click>
> > behaviour? What happens if I <shift>+<click> a set of files then click
> > on another file? With Windows behaviour the selected files would
> > become unselected, whereas the most logical buttons behaviour would be
> > for them to stay in text field (or wherever).
> 
> As I understand it, the file list would reflect the currently selected
> files, and also vice-versa (if you type in a valid file name or a set of
> ; delimited names in the file field, those names would be higlighted in
> the directory view if they are in that directory).
> 
> If you SHIFT + click some range of files (or CTRL+click a set of files),
> and then click another file, all files except the most recently clicked
> one would become unselected, yes (this is the expected behavior).
> 
> The file text field should immediately reflect that and only show the
> name of that single file. This is fully consistent with the "files that
> are selected are also listed in the file list" behavior.

Yes, the behaviour you describe is exactly the same as the windows
behaviour, and that would be my preference. However, what Dylan is
suggesting is the addition of an "add selected" button that would add
the current selection to the list of opened files, but wouldn't open
them until the "done" button was pressed. My point is that this "add
selected" button requires a different behaviour in the file list view.
It only makes sense if the changes in selection don't directly affect
the contents of the text field.


> Another issue about the file box: is it absolutely necessary to show the
> full path, even if "you are" in a particular directory, the directory
> shown in the directory view?

I know it gets long and unwieldy, but I think it's a prerequisite for
being able to select files from multiple directories, as can be done
using an "add selected" button or a Mozilla-style view (my
preference).

> Also, I think it's unnecessary to show the "" around file names that
> don't need them, e.g. files that don't contain spaces or control
> characters or other weird characters.
> This is what bash does when you tab-complete a range of files as input
> to a program - it only puts "" aoround file names that need them.

Agreed.

colin

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