Re: GtkFileChooser API work

[Owen Taylor <otaylor redhat com>]

 On Mon, 2003-09-01 at 23:59, Federico Mena Quintero wrote:

> API: Extra widgets
> ------------------
> 
> We can add a preview widget, but there is no facility to add special
> widgets for applications that need them.  For example, Evolution
> adds a checkbox like this to the "Attach file" dialog:
> 
> 	[ ] Suggest automatic display of attachment
> 
> The GIMP could need widgets to let the user select image compression
> levels or other options.
> 
> I can add functions analogous to set_preview() / get_preview(),
> possibly called set_extra_widget() and get_extra_widget().  Even
> though the current UI is temporary, the extra_widget would be placed
> below the directory and file lists.

That sounds fine to me. It's on the TODO list. 

> API: Is set_preview_widget_active() needed?
> -------------------------------------------
> 
> In GtkFileChooserImplDefault, this just hides/shows the frame that
> wraps the preview_widget.  However,
> 
> 	1. I don't think a frame or any other visible wrapper for a
>            preview_widget is appropriate.  This may prevent
>            applications from making the preview_widget as pretty as
>            they can, because they have to worry about the visible
>            frame around it or whatever appears in the final UI design.
> 
> 	2. If such a default frame is not needed, then why do we need
>            set_preview_widget_active()?  The application which
>            installs a preview widget could just hide/show it on its
>            own depending on whether a preview is available for the
>            selected file.

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.

(Though even if you don't have a frame, you might well want to
change packing.)

It's in the API docs:

 * When there is no application-supplied preview widget, or the
 * application-supplied preview widget is not active, the file chooser
 * may display an internally generated preview of the current file or
 * it may display no preview at all.

Of course, we could recycle gtk_widget_hide/show for this, since 
it's possible to watch notify::visible on the child. I don't really
have an opinion on whether that would be better API.

> API: GtkFileChooserWidget vs. GtkFileChooserDialog
> --------------------------------------------------
> 
> The FOSDEM paper says this:
> 
> 	On a large scale, one distinguishing feature of any API is
> 	that the same set of methods, signals and properties is needed
> 	in several places. We need these aspects of the file selection
> 	interface in the file selection dialog, which is where people
> 	will most often use them. But, to correspond to
> 	GtkFontSelection and GtkColorSelection, we'll also need an
> 	embeddable widget that has the same signature [...]
> 
> Do we really want a GtkFileChooserWidget that is separate from
> GtkFileChooserDialog?  When would people actually embed the file
> chooser widget by themselves in other places?  For the color/font
> selection widgets it makes sense, but I'm not sure it does for the
> file chooser if the whole dialog is supposed to be extensible.

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.

> Feature: configurable directory list
> ------------------------------------
> 
> New versions of Mac OS X have a feature where you can drag directories
> from the file manager and drop on them on the side bar of the file
> dialog.  To remove a directory from the side bar, you just drag it
> off.  The idea is to keep your working set of directories there; you
> tend to work on a few projects at a time and so it makes sense to keep
> your frequently-accessed directories close at hand.  When your
> projects change, you just change the directories in the side bar.  See
> the screenshots here:
> 
> 	http://www.atommic.com/images/panther/OpenBox.jpg
> 	http://www.atommic.com/images/panther/SaveBox.jpg
> 	http://macnet2.com/panther/pictures/save-box.html
> 	http://macnet2.com/panther/pictures/photoshop-savebox.html
> 
> This is easy to support, but we need a way to save the set of
> directories that the user has configured.  Should GTK+ simply write a
> ~/.file-chooser-directories, or do we need something more complicated?
> 
> I'd love to have this in the base GTK+ file selector rather than
> having to create a replacement in libgnomeui or gnome-vfs --- as far
> as I can tell, GTK+ has never written configuration data in the past,
> but for such a simple thing we should not need something exotic.
> 
> For the sake of completeness, we may want
> 
> 	GSList *gtk_file_chooser_list_user_directories (GtkFileChooser
> *chooser);
> 	[returns a list of const gchar *]
> 
> And do we need a way to set a default list of directories?  Can we
> just populate the immutable part of the list from a few well-known
> locations like ~, ~/Desktop, removable volumes, etc.?

>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.

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

> Nitpicks
> --------
> 
> "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.

Regards,
						Owne