Re: File Dialog

[Kent Schumacher <kschumacher uswest net>]

Vlad Harchev wrote:
> 
> On 25 Aug 2000, Havoc Pennington wrote:
> 
> >
> > matthew <matthew@mattshouse.com> writes:
> > > I disagree with this.  Just because the Merced isn't available yet doesn't
> > > mean that we should stick to the 486, eh.  We can still upgrade.
> > >
> >
> > As long as it isn't a new API, just enhancing the widget with the
> > current API, then I agree.
> 
>  OK, here is my proposal on extending API of the current GtkFileSelection
> widget. I should say, that API is the first thing to think about IMO - the
> visual appearance is the 2nd thing, and it could be easily altered provided
> API is chosen wisely.
> 
>  Add the following arguments to the widget:
> 
> directory:string  the initial directory

> 
> file-pattern:string    the filename pattern. In the ideal world, it should be
>         extended regular expression to allow    multiplie patterns in one,
>         e.g. (.*\.[jJ][pP][gG])|(.*\.[pP][nN][gG]) will show jpeg and png
>         files.
> 
> pattern:string - this is the way to set directory and pattern with single
>         subpattern in one argument.
> 
> filename:string   initial file selection (or contents of filename entry
>         widget, if any). This could be used by wise software that can predict
>         what filename the user will use. Setting this to something shouldn't
>         be equal to performing tab completion (i.e. shouldn't affect list of
>         files)!
> 
> show-hidden:bool        whether hidden files (dotfiles on unix and hidden
>         files on windows) are shown.

I personally would like this to apply to each successive instance of the
file
selector.  I often bring multiple tools to bear on a single file or set
of files
as I work on things, and I find it convenient to be able to maintain
settings
across applications.  Of course I also have found instances where this
is not what
I want... (grin?)

> 
> show-fileops:bool       IMO it's a bad idea to have this argument if we are
>         going to allow custom file selectors, but we can have this argument
>         just for current _internal_ GtkFileSelection (not requiring such
>         argument from every implementation of GtkFileSelection).
> 
How about we have a fileselector that is really good at selecting files,
and
instead of fileops we have the ability to open a file manager window
(Nautilus?) on
the current directory displayed in the fileselector.  The file manager
would need to
be able to tell the fileselector to update itself when changes are made
to the
directory structure...  Having this would save the user from having to
learn to
sets of file ops, and it would keep the file selector focused.


>  Functions:
> Functions that set the widget's arguments listed above.
> 
> Also ability to set the following predicate functions:
> typedef gboolean (*path_predicate_t)(gconst gchar* name,gpointer data);
> 
> /*
>         When this predicate function is set, only directories for which it
>         returned 'true' will be shown/allowed to be visited/matched.
> */
> void gtk_file_selection_set_directory_show_predicate(GtkFileSelection
>         *filesel,path_predicate_t pred);
> 
> /*
>         When this predicate function is set, only files for which it
>         returned 'true' will be shown/allowed to be matched.
> */
> void gtk_file_selection_set_file_show_predicate(GtkFileSelection
>         *filesel,path_predicate_t pred);
> 
> Also it would be nice if it was possible to use custom sorting function for
> files and directories (separately).
> 
>  As for extending visual appearance/usability of current GtkFileSelection:
> 1) My personal wish - put ".." above "." - i.e. make it 1st item in the list
> of directories
> 2) Add accelerators for each element - each list and probably fileop. Add
> accelerator for rescanning current directory. Add accelerator for going up one
> level.
> 3) Probably adding button for going up one level since not every windows-guy
> know meaning of "..".
> 4) While support for X resources is not available in gtk, it would be nice if
>  it was possible to set default dimensions for file selection window via
>  environment variables (like GTK_FILESEL_WIDTH,GTK_FILESEL_HEIGHT) (as for me,
>  the first thing I do when some gtk filesel dialog pops up - increasing its
>  size).
> 
>  It seems that all functions I propose will be meaningful for any
>  implementation of GtkFileSelection.
> 
> > Havoc
> >
> > _______________________________________________
> > gtk-devel-list mailing list
> > gtk-devel-list@gnome.org
> > http://mail.gnome.org/mailman/listinfo/gtk-devel-list
> >
> 
>  Best regards,
>   -Vlad
> 
> _______________________________________________
> gtk-devel-list mailing list
> gtk-devel-list@gnome.org
> http://mail.gnome.org/mailman/listinfo/gtk-devel-list