Re: GtkFileChooser API changes

[Owen Taylor <otaylor redhat com>]

On Mon, 2003-10-13 at 15:47, Federico Mena Quintero wrote:

> Application-side shortcuts
> --------------------------
> 
> Say you have a drawing program, foodraw.  When you install it, it
> creates a /usr/share/foodraw/Clipart directory.  It would be good if
> foodraw gave you an easy way to access the clipart directory any time
> you want to open a file.
> 
> I added these functions:
> 
> /* Takes a list of GtkFilePath */
> void gtk_file_chooser_set_shortcut_folders (
> 	GtkFileChooser *chooser,
> 	GSList         *shortcut_directories);
> 
> /* Returns a list of GtkFilePath */
> GSList *gtk_file_chooser_list_shortcut_folders (
> 	GtkFileChooser *chooser);

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]()

> There are also the corresponding virtual methods in
> GtkFileChooserIface.  The implementation is supposed to just list the
> specified folders somewhere in the GUI.  The default implementation
> shows them in the combined shortcuts/bookmarks list.

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)

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

> User-configurable bookmarks
> ---------------------------
> 
> These are similar to the bookmarks you can set in the file selection
> dialog of Mac OS X Panther:
> 
> 	http://www.atommic.com/images/panther/OpenBox.jpg
> 
> The is that you drag commonly-used directories into the list on the left
> part of the dialog, and it will keep them for you.  This lets you access
> your "working set" of directories easily.  When you stop using a
> directory in your current projects, you just drag it away from the list
> to remove it.
> 
> There is no public API for this, as it is the job of the internal
> GtkFileSystem implementation to store the bookmarks.  Currently
> GtkFileSystemUnix says "I don't support bookmarks", and
> GtkFileSystemGnomeVFS stores the bookmarks using GConf.
> 
> The internal API in GtkFileSystem is this:
> 
> gboolean gtk_file_system_get_supports_bookmarks (
> 	GtkFileSystem *file_system);
> 
> /* Takes a list of GtkFilePath */
> void gtk_file_system_set_bookmarks (
> 	GtkFileSystem *file_system,
> 	GSList        *bookmarks,
> 	GError       **error);

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