Re: File dialogs: an attempt at a summary

[Christian Rose <menthos menthos com>]

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.


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?

Consider that the file dialog lists the contents of
/home/user/my_documents/pictures/florida_vacation. Isn't it terribly
inconvienient to list the whole path of all selected files in the file
name field?

e.g:
/home/user/my_documents/pictures/florida_vacation/pic1.jpg;
/home/user/my_documents/pictures/florida_vacation/pic2.jpg;
/home/user/my_documents/pictures/florida_vacation/pic3.jpg; 
/home/user/my_documents/pictures/florida_vacation/pic4.jpg; 
/home/user/my_documents/pictures/florida_vacation/pic5.jpg;
/home/user/my_documents/pictures/florida_vacation/pic6.jpg

could quickly become a list that is completely horrible in the small and
limited visible part of a file name field.

My suggestion is that only the relative path to the currently viewed
directory is shown. This would make the list in the example above:

pic1.jpg; pic2.jpg; pic3.jpg; pic4.jpg; pic5.jpg; pic6.jpg


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.

Comments?


> > > Save as file type:
> > > Save dialogs must allow the user to select which file format the file
> > > should be saved in. Implementation unclear.
> >
> > BAD BAD BAD DANGER DANGER DANGER!
> >
> > Repeat after mean:
> >
> > A file is a stream of bytes. A file is a stream of bytes. A file is a stream
> > of bytes. A file is a stream of bytes. A file is a stream of bytes. A file
> > is a stream of bytes. A file is a stream of bytes. A file is a stream of
> > bytes.
> >
> > Do not go enforcing some format through a common dialog box!  There lies
> > madness!!!
> 
> A file is a stream of bytes, generally with some sort of format. Pngs
> have compression, wavs have headers... Look at the Gimp save dialog to
> see what I mean by this.

Yes, a format needs to be specified in most apps, and the save dialog
should have the ability to choose from a range of formats.


Christian



#######################################################################
Christian Rose
http://www.menthos.com                    	    menthos@menthos.com
#######################################################################