Re: New treeviewized GtkFileSelection and GTK_SELECTION_MULTIPLE

Manish Singh <yosh gimp org> writes:

> A bit of an addendum:
> > Proposed API additions:
> > 
> > 1) gtk_file_selection_set_selection_mode (): simply a wrapper around
> >    gtk_tree_selection_set_mode () for the fs->file_list
> Also, a corresponding get_file_selection_get_selection_mode ()
> > 2) gtk_file_selection_get_selections (): Returns an array of filenames,
> >    freed by the caller.
> It should also return whatever the user typed in the entry widget, and
> prepend the directory names to all the filenames. I'm not sure I like the
> function name, anyone have any better suggestions?

 * On reflection, as much as I don't like adding API at this point, I think
   we need to do this. Multiple file selection is used in various current
   users of GTK+-2.0 (the GIMP, libbonoboui/bonobo/bonobo-list) and probably
   a elsewhere not using GTK+-2.0 yet, so currently we have
   a reasonably large functionality regression.

 * Adding the API explicitely is definitely better than adding the API
   implicitely by making it work if you poke into the internals in a certain

 * I think it's probably worth spending the effort to make the filename
   in that's put into entry not the first item among the selected items,
   but the most recently selected item. (More exactly, the first newly
   added item when the selection changes.)
   Unfortunately, the only clean way to do this that I (or Jonathan) could
   think of is to to keep track of the current selection and do diffs
   in selection::changed.

The proposed API looks fine, except that I'd like to see;

 gtk_file_selection_set/get_select_multiple (GtkFileSelection *filesel, gboolean select_multiple);

Then reusing the selection enum, since the "NONE" selection mode
doesn't make sense.


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]