Re: GtkFileChooser API work

[Federico Mena Quintero <federico ximian com>]

On Tue, 2003-09-02 at 15:23, Owen Taylor wrote:

> > API: Extra widgets
> That sounds fine to me. It's on the TODO list. 

OK, I'll put it in.

> > API: Is set_preview_widget_active() needed?
> The point of set_preview_widget_active() is not the frame but rather
> to allow the file selector to show it's own preview when the
> applications preview is not present.

The question is whether the base implementation will actually have a
preview.

I think a default preview implementation is not needed.  An image viewer
that uses the file chooser will certainly want to display thumbnails of
image files in the preview area, but it doesn't make much sense for it
to e.g. display the first few lines of text files.  Likewise, a text
editor may want to display the first few lines of text files, but not
display images at all.

I'd rather have a file list that displays more useful information ---
filename and mtime seem to be about everything you would need, and
perhaps file size as well.

I guess user testing will really tell whether we need a default
implementation for a preview widget.

> > Do we really want a GtkFileChooserWidget that is separate from
> > GtkFileChooserDialog?
> I don't know of a lot of uses ... the only place I've seen an
> embeddable file selector is in Qt's 'designer' app.
> 
> The main reason for the split is simple consistency with the other
> dialogs. (Though you could argue that it's not really consistent
> in *how* it's done.)
> 
> I think the overall design worked out pretty well, and will let
> us do replacable UIs in the future, which is somewhat important.
> And with the overall design GtkFileChooserWidget is basically free.

Yeah, it's basically free.  I was just wondering if we could reduce the
public API a bit.

> > Feature: configurable directory list
> From the API point of view, this just sounds like a directory bookmarks 
> feature. Originally, I was thinking that this would be something
> that the FS backend would implement, but maybe it's better just
> hardcoded per platform. On non-free desktops, if the native file
> selector has bookmarked directories, we should be using the same
> backend as that.

I'm thinking of where to put that API.  We can have it as extra methods
in the GtkFileSystem interface, something like

	/* signal */
	void bookmarks_changed (GtkFileChooser *chooser);

	/* methods */
	gboolean supports_bookmarks (GtkFileChooser *chooser);
	GSList *list_bookmarks (GtkFileChooser *chooser);
	void set_bookmarks (GtkFileChooser *chooser, GSList *bookmarks);

The file chooser GUI would call ::supports_bookmarks() on the file
system implementation, and hide or show the bookmark list as
appropriate.  I'm not terribly happy about "supports"-type methods, so
we could also just have a GtkFileSystemBookmarks interface, and the file
system implementation may support it or not.

What is preferable?

> Note that from a UI point of view, DND should never be the *only*
> way of doing something.

We can have an "add current directory to bookmarks" button in the
dialog.  OS X has an "add to favorites" button, I think.

> > "GtkFileChooserImplDefault" is a horrible name.  Can we replace it
> > with just "GtkFileChooserDefault"?
> 
> Implementation detail. gtk_file_chooser_impl_default() does get a bit
> tiring to write. If you want to sed script to rename it and fix
> the indentation, that's OK with me.

Will do :)

  Federico