Re: RFP: File chooser user interface

[Magnus Bergman <magnus bergman observer net>]

On Tue, 16 Sep 2003 10:16:10 +0100
Thomas Leonard <tal00r ecs soton ac uk> wrote:

> On Mon, Sep 08, 2003 at 10:27:48AM -0400, Owen Taylor wrote:
> 
> > This is a request for proposals for how the file selection user
> > interface; what we are hoping to do is to get a number of user
> > interface proposals, pick one or combine elements from multiple
> > proposals, implement a first draft, and then refine from there.
> 
> I think this scheme has already been dismissed, but I'll present it
> anyway for completeness.
> 
> I won't talk about Open dialogs. I guess most people open files from
> their filemanager, drag-and-drop to the application, or use
> cut-and-paste. Having a separate dialog for this seems unnecessary,
> but could be useful in emergencies as an expert feature, I suppose.
> 
> As others have suggested, please ensure that the saving and loading
> APIs are separate, so that the dialogs can be presented differently.
> 
> The save box looks like this:
> 
>   +------------------+
>   |                  |
>   |     +------+     |
>   |     |      |     |
>   |     | Icon |     |
>   |     |      |     |
>   |     +------+     |
>   |                  |
>   | [Filename______] |
>   |                  |
>   |  [Cancel] [Save] |
>   +------------------+
> 
> Users enter a name for the file, and then drag the icon to their
> filemanager or a desktop icon, etc.
> 
> If the file has been saved before, 'Filename' is the complete path,
> with the leafname selected by default. This allows easy resaving to
> the same directory (Draft1, Draft2, etc) without extra dragging (the
> user saves by pressing Return or clicking Save in this case).
> 
> Advantages:
> 
> - Very small, simple dialog.
> 
> - After saving, the file manager window is open, showing the saved
> file.
>   This is exactly the view the user will see when opening the file
>   later, avoiding the problem others mentioned that the user may not
>   recognise their saved file.
> 
> - Can (possibly) save to other applications, eg by dragging an image
> from
>   Gimp's savebox into a KWord frame.
> 
> - Since the user's filemanager is involved, all normal functions
>   (searching, bookmarks, recently visited directories, rename, etc)
>   are available, with a familiar interface.
> 
> - No problems about which 'default' directory to use. If the user
> wants to
>   use a directory again, they keep the filer window open. Also, this
>   allows automatic sharing between applications (I can save from Gimp,
>   and then drag the newly saved file from that directory into KWord,
>   etc). Any number of directory windows can be kept open (or
>   minimised, etc).
> 
> - Desktop icons and panels can be used automatically.
> 
> - No need for thumbnailing, filters, properties, etc. The file manager
>   provides all that.
> 
> Power users can enter a filename with tab completion (or whatever
> other completion system we use). If a path component doesn't exist
> when the user clicks Save, they are asked whether they want to create
> it as a directory.
> 
> The system is already implemented. Screenshots:
> 
> http://rox.sourceforge.net/phpwiki/index.php/HintsAndTips
> http://rox.sourceforge.net/archive.html

This must be he most interesting proposal so far. I personally like idea
very much, but I don't think the world is ready for it yet.

Just one question: How do you save a file without using the mouse?

> Of course, people may not want this as the default (compatability with
> Windows is important to many people here). Some useful things to have,
> though:
> 
> - Separate save and open APIs.
> 
> - Save API:
>   - Application provides MIME type and default name.
>   - Save box provides application with a pathname to save to.
>   - Application indicates when save is finished.
>   - Save API tells application the new name (URI).

I agree with this completely. I was developing a module for Gnome VFS a
while ago. And I came across a couple of situations there it was
necessary for the module to decide the exact filename. It would be great
if all GTK applications could handle such situations.

>   This allows us to implement drag-and-drop and saving to remote
>   machines, etc, by asking the application to save to a temporary file
>   and then sending that (this is why the new name may not match the
>   path the app saved to).
> 
> - Please, replace all Rename, Delete, New directory, etc buttons with
>   'Open directory in filemanager' button. This is pointless
>   duplication, whatever filemanager the user prefers.

I don't consider that a good idea. I think you should either have it
completely dependant on the file manager, or completely independent of
the file manager (the latter is appropriate for the default GTK FOSD
since GTK shouldn't need to know about external applications at all).

> Hope that's of some interest...