Re: GtkFileChooser API changes

[Federico Mena Quintero <federico ximian com>]

On Tue, 2003-10-14 at 07:40, Owen Taylor wrote:

> GtkFilePath is not public; neither are the functions to convert between
> GtkFilePath and filenames/URIs. While it's expands the number of entry
> points quite a bit, I think it's more consistent with the rest of the
> API, more convenient, and clearer to have:
>  gtk_file_chooser_add/remove/list_shortcut_folders()
>  gtk_file_chooser_add/remove/list_shortcut_folders_uri[s]()

OK, I just made these changes.  I have

gtk_file_chooser_add_shortcut_folder()
gtk_file_chooser_remove_shortcut_folder()
gtk_file_chooser_list_shortcut_folders()

gtk_file_chooser_add_shortcut_folder_uri()
gtk_file_chooser_remove_shortcut_folder_uri()
gtk_file_chooser_list_shortcut_folder_uris()

I'm thinking that I really don't like the file/uri duplication in the
API.  Would it be reasonable to have an API that only deals with URIs? 
Applications that only deal with local files can a) easily trim the
"file://" prefix, and b) start considering the use of gnome-vfs :)

> Is there any indication to the user which ones of the combined list
> can be removed and which ones are fixed? (Not saying there should
> be necessarily, just curious)

The fixed ones are the file system roots and the shortcuts provided by
the application (e.g. "Clipart").  If you select one of them, the
remove-bookmark button is de-sensitized.

Likewise, you can't add a folder twice to the bookmarks list.  If the
current folder happens to exist already among the shortcuts or
bookmarks, the add-bookmark button is de-sensitized.  The rationale for
this is that whenever you change into a folder, as if you double-click
on a folder in the file list, then if that folder exists among the
shortcuts or bookmarks, it gets highlighted there.  Having multiple
bookmarks of the same folder would be confusing --- "why did it select
that one but not *that* other one?  Oh, they are the same...".

> Looking at the gtkfilesystem.h, you have shortcut handling there
> in addition to bookmarks. Why?

Oops, those were remains of some cut&paste action.  I just removed them;
thanks for catching that.

> I really don't like this "set an entire list" approach
> 
>  - There will be no indication of which bookmark causes the error
>  - The backend may need to diff the old and new lists
>  - It's less typesafe than alternate approaches
> 
> As above, I'd like to see this split into add/remove/list
> 
> Is it worth making this an optional feature? It's probably only 
> 100 lines of code or at most to create a ~/.gtk-bookmarks
> implementation for the Unix backend that would still be very
> useful to users.
> 
> > /* Returns a list of GtkFilePath */
> > GSList *gtk_file_system_list_bookmarks (
> > 	GtkFileSystem *file_system);
> > 
> > Of course, there are the corresponding virtual methods in
> > GtkFileSystemIface.
> 
> I think there probably should be change notification; it could
> be considered overkill, but it's really a nice touch when change
> notification works everywhere. (Obviously, you can't change
> notify on ~/.gtk-bookmarks, but it's easy with GConf)
> 
> > Activating a file
> > -----------------
> > 
> > What happens when the user double-clicks on a file, or when he hits
> > Enter?  I added a signal as GtkFileChooserIface::file_activated().
> > 
> > The implementation of GtkFileChooserDialog catches this signal and
> > activates the default button in the dialog, which would normally be the
> > "Open" or "Save" button.
> > 
> > However, since you can also take a non-dialog GtkFileChooserWidget and
> > embed it somewhere else, you can also connect to the "file-activated"
> > signal by yourself and do whatever is appropriate for your application.
> > 
> > The signal is simply
> > 
> > struct _GtkFileChooserIface {
> > 	...
> > 	void (*file_activated) (GtkFileChooser *chooser);
> > };
> > 
> > >From your signal handler you can use gtk_file_chooser_get_uris() or any
> > of the similar functions to get the list of selected files.
> 
> Should this have a boolean return and be a true-stops-emit
> (g_signal_accumulator_true_handled) signal? It seems like something that
> only one party should handle.
> 
> Regards,
> 						Owen
> 
> 
> _______________________________________________
> gtk-devel-list mailing list
> gtk-devel-list gnome org
> http://mail.gnome.org/mailman/listinfo/gtk-devel-list
>