GtkFileChooser API work

[Federico Mena Quintero <federico ximian com>]

Hi,

I'm about to dedicate at least two weeks full-time to GtkFileChooser,
hoping that it will have a chance of going in GTK+ 2.4.  I would
appreciate people's comments on the following points:

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.

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.

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.

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

Nitpicks
--------

"GtkFileChooserImplDefault" is a horrible name.  Can we replace it
with just "GtkFileChooserDefault"?

Footnote
--------

Most of the above is API-related, as a design for the user interface has
not been finalized yet.  File selection dialogs can elicit big
flamewars, so please keep the comments related to the API, not the user
interface :)

  Federico