Re: File dialogs: an attempt at a summary

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

On Thu, Aug 17, 2000 at 12:27:42AM -0600, Dylan Griffiths wrote:
> 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.

Great. Thanks. That'll be very helpful. Someday I should start messing
around with GTK+ 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 :)

Damn right we are! :)


These are meant to be the uncontroversial things, but...

> > 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. 

Certainly. I don't think it could work any other way.

> 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).


> 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."

Rather than saying "no preview available" it could do something a
little more helpful like showing file attributes: created, last
accessed, size, permissions, etc...


> > 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.


> > 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.. 

Perhaps, but I'm still into having multiple representations. And I'm
still keen on Mozilla-style. I know, I know. If I want it I should
contribute some code.

colin

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