Re: [Usability] Re: RFP: File chooser user interface

[Magnus Bergman <magnus bergman observer net>]

On Tue, 09 Sep 2003 16:07:15 -0500
Lars Clausen <lrclause cs uiuc edu> wrote:

> Glad to hear some serious discussion of a new file chooser dialog. I
> agree with most of what's been said, but here's a little comment to
> Magnus' ideas.
> 
> On 9 Sep 2003, Magnus Bergman wrote:
> [...]
> > 2 No context menus or hidden features.
> >
> > I appreciate that the current GTK file dialog has no context menus.
> > I think it makes it fell robust and reliable, and of course easy to
> > overview.
> 
> Context menus are easily found and so common now that they aren't
> really a hidden feature anymore.  I wouldn't mind them in the chooser,
> except I can't see any non-redundant uses for them.  I think context
> menus in general are a good thing, as it makes it easier to find
> functions related to an item.

I didn't mean to suggest that context menus are hidden features, just
that I don't want them in dialogs. I agree that they are a good thing in
general. I think all the features of a dialog should be clearly visible,
and also simple enough for that to be possible. In other words, I
believe that dialogs should be designed a way which makes context menus
unneeded. Ideally, tool tips shouldn't be needed either.

> > The hidden feature (filtering and completion) in the current GTK
> > file dialog is quite nifty, if you know about it. But the fact that
> > it is hidden makes it useless to most people. I think the best
> > would be to have a special widget for filtering. There the user can
> > select a predefined filter or enter her own. Auto completion is not
> > very useful in a file dialog anyway and can be removed without
> > being missed too much I think. 
> 
> I pretty much agree with this.  The completion feature in the old file
> dialog was a real pain when modifying it and rarely of any use.  It
> should indeed be a filter thing instead.

It has come to my knowledge that there is a minority of users who make
heavy use of the auto completion feature. So I've been that convinced
that it must stay. But I'd like it to be disabled by default (so the tab
key works as expected).

> > (3) Root selection
> >
> > I don't really have any good idea what to call this, but the idea
> > is to let the user choose between different directory trees. On DOS
> > like systems it has an obvious use. (Actually I stole this idea
> > from GEM which I use on my Atari ST). On plain UNIX like systems
> > (without Gnome or such) this widget might be pointless, but it
> > would be useful for the directory bookmark feature discussed
> > earlier. Alternatively its content could always be either appended
> > or prepended to the content in the directory selection widget(4).
> > This is a popular design in many DOS programs.
> 
> One thing I really want in a file chooser is a simple way to go to ~/
> (and no, entering "~/" in the file name and pressing TAB is not
> simple).  One could think of the 'Root selection' item as a
> 'Frequently used places' item, which would contain the DOS file
> systems, or ~/, /tmp etc for Unix systems, possibly extensible by the
> user.  But some way to go to $HOME is needed. 
> 
> > (11) Some other optional widgets supplied by the application
> >
> > If the application wants to add extra widgets to the dialog they
> > should be placed here. I can not think of any other use for this
> > than to give the user some option related to how the file (or
> > directory) should be opened or saved. If there exists sane cases
> > there widgets with other uses are needed, maybe they should appear
> > somewhere else?
> 
> I find that I need the optional widgets to change depending on the
> filter selected.  For instance, when saving as PNG, I want to specify
> pixel size, when saving to PS I want to specify paper sizer and
> whether to embed fonts.  An easy way to handle this would be
> appreciated.

I think that can easily be solved by emitting a signal to the
application then the filter selection changes (I think that will be
possible without any additional feature in the dialog itself).