Ready to merge / last API change [Was Re: Finished reviewing kris-async-branch]

[Kristian Rietveld <kris imendio com>]

Hey,

After some last hacking today, I am ready to merge.

1) I made one last change to the GtkFileSystem interface, the
"volume_render_icon" method has been replaced with "volume_get_icon_name". 
gtk_file_info_get_icon_name() has been added, gtk_file_info_render_icon() is
still there as a helper function, but the caching code has been removed.
Also gtk_file_system_volume_render_icon() is still there as a helper function.  The full patch can be seen here:

  http://people.imendio.com/~kris/filechooser-review/patch-volume-render-icon-to-get-icon-name.diff

Patch for the gnome-vfs backend:

  http://people.imendio.com/~kris/filechooser-review/patch-gnome-vfs-volume-render-icon-to-get-icon-name.diff


2) When I merge I will probably have to increase the GTK_BINARY_VERSION
to 2.9.0.  Am I right here?


If nobody objects I will merge tomorrow evening (and increase the binary
version).


On Fri, Apr 28, 2006 at 01:36:45PM -0500, Federico Mena Quintero wrote:
> + General comments:
> 
> 	+ I don't like the fact that from the caller's viewpoint,
> 	  memory management of handles is different depending on
> 	  whether you canceled the operation or not.  If you didn't
> 	  cancel the operation, you must unref the handle in your
> 	  callback.  If you canceled the operation, your callback must
> 	  not unref the handle (i.e. gtkfilesystemgnomevfs unrefs the
> 	  handle after calling it).

This was a little bug/thinko in the original code.  You always have to
unref your own handle in the callback.  The code has been fixed to
reflect this.

> 	+ The code in gtkfilechooserdefault has gotten way too
> 	  complex.  Please please please write a good document on the
> 	  internals so that future hackers will have a chance of
> 	  understanding it.

Will do ;)


thanks,

-kris.