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

[Maynard Kuona <knxmay001 mail uct ac za>]

How about task pane style dialogs too. These could be pretty useful too,
if there are no patents on them.

On Mon, 2003-09-15 at 18:20, Magnus Bergman wrote:
> 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).
> _______________________________________________
> gtk-devel-list mailing list
> gtk-devel-list gnome org
> http://mail.gnome.org/mailman/listinfo/gtk-devel-list