Re: File dialogs: an attempt at a summary

[Dylan Griffiths <Dylan_G bigfoot com>]

colin z robertson wrote:
> It turns out that there are still a number of significant grey areas
> to be finished off. Over the next few posts (split up to make the
> discussion a little cleaner) I'll try to describe those areas and
> hopefully something can be worked out without too many casualties.

Regardless of gray areas, I'm going to be working on implementing proof of
concept dialogs for myself.  <rant>This is hindered by the [explicitive
delete] state of the GTK+ and Gnome library documentation, so don't expect
something soon.  So far in my programming with GTK+/Gnome, I've had to write
a proof of concept app for each new widget I've encountered, due to the
state (or lack thereof) of the documentation.  Win32 programming wasn't this
hard because at least MS gave you some documentation.</rant>  I'll try to
keep in touch with the list on it, as I know they're all flame warriors
itching to tell me what I've done wrong :)
 
> First, though, here are the things that I think are fairly
> uncontroversial, where I believe a consensus has been reached:
> 
> Button naming:
> Open/Cancel.

*
 
> Single and multiple selection:
> When opening files it is sometimes necessary to select multiple files
> at once. This must not make the selection of a single file any harder.
> (I take this to mean that the dialogs for multiple and single
> selection must be similar enough that the user would perform the same
> actions in a multi-select dialog as they would in a single-select
> dialog to select a single file.) Highlighting multiple files with
> <shift>+<click> and <ctrl>+<click> seems to be the way to do this.

*

I'm hoping that it'd be fairly easy to give a gboolean to the dialog
indicating if it should ask for a single file, or ask for multiple files. 
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"

Also, adding a "preview" section to the dialog which attempted to launch an
embedded bonobo control associated with the mime type could be an
interesting experience (if any docs on this ever surface).  An embedded MP3
player would have play and stop, an embedded image viewer would show a
scaled down image, etc.  Otherwise, "no preview available."

> Recently used directories:
> A drop-down list of directories from which files have recently been
> opened by that app should be included.
> 
> 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!!!
 
> I'm not going to address the issue of how files and directories should
> be displayed right now, partly because I'd like to see the results of
> other discussions first and partly because I need to give it some more
> thought myself, but mostly because it's already 1am.

I always thought that the dir treeview + file listview would be enough.. 
-- 
    www.kuro5hin.org -- technology and culture, from the trenches.