Re: Adding error reporting to GtkFileChooser

[Mark McLoughlin <mark skynet ie>]

Hi,

On Wed, 2004-03-03 at 16:45, Owen Taylor wrote:
> On Tue, 2004-03-02 at 15:48, Federico Mena Quintero wrote:
> > Some functions in GtkFileChooser don't report errors back to the caller:
> > 
> > 	gtk_file_chooser_set_filename
> > 	gtk_file_chooser_select_filename
> > 	gtk_file_chooser_unselect_filename *
> > 	gtk_file_chooser_set_current_folder
> > 	gtk_file_chooser_set_uri
> > 	gtk_file_chooser_select_uri
> > 	gtk_file_chooser_unselect_uri *
> > 	gtk_file_chooser_set_current_folder_uri
> > 	gtk_file_chooser_set_current_name **
> > 
> > These all return void and take a string argument.  Are we truly
> > API-frozen, or should I make them return gboolean and take in a 
> > GError **?
> 
> We are hard API/ABI frozen at this point, but this is by policy, not
> by necessity, so if we need to make an exception we can make an
> exception, with the downsides:
> 
>  - We will cause people to re-roll GNOME tarballs that use
>    these functions.
>  - We cause language binding authors to have to re-rev
>  - We could possibly (though probably not here) regress with 
>    these API changes and be in worse trouble
>  - We look lame

	From a release-team perspective, we would be extremely dissappointed if
GTK+ broke its API freeze 5 days before the 2.4.0 release is supposed to
happen.

	As regards re-rolling GNOME tarballs affected by this change - from a
quick grep of my source tree, eog, epiphany, file-roller, gedit, ggv,
gnome-applets, gnome-panel, gnome-utils, gpdf, libbonoboui libgnomeui,
libgnomeprintui, nautilus-cd-burner and zenity all use these functions.
Anything that uses the file chooser basically.

	There is no question in my mind that this change would delay the GNOME
2.6.0 release date.

	Its down to you guys to make the call, but I would urge you to just
suck it up and stick with the freeze.

Good Luck,
Mark.