Re: New treeviewized GtkFileSelection and GTK_SELECTION_MULTIPLE
- From: Manish Singh <yosh gimp org>
- To: Owen Taylor <otaylor redhat com>
- Cc: gtk-devel-list gnome org
- Subject: Re: New treeviewized GtkFileSelection and GTK_SELECTION_MULTIPLE
- Date: Mon, 4 Feb 2002 15:16:58 -0800
On Mon, Feb 04, 2002 at 06:00:44PM -0500, Owen Taylor wrote:
> 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.
All sounds fine to me, I'll come up with a patch tonight.
] [Thread Prev