Re: Adding error reporting to GtkFileChooser

[Michael Natterer <mitch gimp org>]

Mark McLoughlin <mark skynet ie> writes:

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

Where, really *where* is the problem in delaying the GNOME 2.6.0
release a bit? I thought this is free software which is ready when
it's ready and not some marketing and deadline driven commercial
product.

How can a release "deadline" of a free software project ever be more
important than getting the API right? Esp. if getting it right doesn't
involve weeks of discussion but just immediately doing it?

So please, please let's try to get a GtkFileChooser that doesn't suck,
add this API and let GNOME be what it is: a project depending on GTK+,
and not the project dictating GTK+.

ciao,
--mitch