Re: File dialogs: File management

[Christian Rose <menthos menthos com>]

Fabrice Colin wrote:
> > File management capabilities:
> > What file management capabilities should the dialog have?
> >
> I would go for Rename, Delete and Create Directory.

Yes. Of course, "Rename" and "Delete" should be able to rename and
delete files as well as directories, just to make sure that there won't
be a hole in the dialog spec. :-)

But don't forget that there should probably be also other buttons in the
dialog, that don't have with file management to do but only navigation.
"Jump to directory above in the hierarchy" is one that I don't want to
miss. It makes it _so_ much easier than having to double-click the nasty
small, away-scrollable ".." entry.

Also, the drop-down "Show as ..." is IMHO a necessity for selecting
different views.


> > On the other hand opening and saving often necessitates some
> > reorganisation of the existing files. Forcing the user to open up a
> > file manager in order to do so is inconvenient.
> Agreed. What about right clicking on the files list to open
> a contextual menu ?

I read the page about Win95 file dialog criticism (the link was posted
here) and one of the criticisms was that many operations were only
provided by right-clicking files/directories in the box.
Right-clicking isn't very intuitive.
I think that what the writer meant was that right-clicking should only
be provided as another way to do some operations.
I.e. we would still need buttons for Rename, Delete and Create
Directory, and _then_ we could have a right-click menu for that too.


> Ideally, file renaming and directory creation wouldn't popup
> a dialog box to prompt for a name, but the user would be
> given the possibility to directly edit the field in the
> list.

Yes. I hate additional dialogs that popup from operations inside dialogs
(!)... can you say "dialog hell"?

Also don't forget that window managers _can_ behave really stupid and be
buggy and don't place popped-up dialogs "on top", or when the user
cycles between windows for a short moment, the dialog could end up below
all other windows. A dialog that needs input for the program to
continue...

This is why I think that one should be really careful when saying "oh,
we'll just pop up another dialog for that". That concept may work fine
in Windows and on MacOS but not on various unixes with a million
different window managers where you cant be really sure of the window
managers behavior with placements of dialogs (or windows for that
matter).

Even if you only expect the user to use Sawfish (as the default GNOME
window manager) you can't be sure or control how Sawfish behaves from
one version to another. Also, different Linux distributions ship
different Sawfish defaults, and options/behaviors get added and removed
from Sawfish all the time.

In my experience, Sawfish currently also has a lot of bugs.

In short I don't think we should make design decisions that makes us
heavily dependant on correct, fully controllable, window manager
behavior. Heavy use of additional pop-up dialogs is such a one (of
course, most confirmation needs such dialogs, I don't know how to solve
that, but at least don't make an additional dialog that would only
contain a text entering field when you can avoid it).

On the other hand, I love the idea with making renaming work the way it
does in Windows - by directly manipulating the file names in the dialog
itself (I assume you all know how it works).


Christian



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