Re: Adding error reporting to GtkFileChooser

[Owen Taylor <otaylor redhat com>]

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

Looking lame should never be a criterion for whether or not to
do something, so if the benefits outway the first downsides,
we should make the change. (So, to make the change, I'd like
to get release team and bindings authors sign off on it first.)

Certainly, if we don't do anything, we can recover later at
the cost of API ugliness.

 - Boolean returns can be added at any time without breaking  
   compatibility
 - Error out parameters could be added by duplicating the 
   API

     gtk_file_chooser_select_uri_checked()

  or whatever. We could also have 
     
    gboolean gtk_file_chooser_get_error (GError *error);

  though that's pretty inconsistent with what we do elsewhere.

Federico - can you give a concrete example of:

 - Why an application would get an error calling one
   of these functions
 - What it would do in response to that when it got
   the error?

GErrors really only make sense when they improve the user experience
for the user.

> The functions marked with an asterisk may not need an error code, but
> they still hand their path argument to _gtk_file_system_model_path_do(),
> which expects a valid path.  Maybe they do need the error code after
> all.

I think internal implementation details shouldn't affect the 
API :-), though question is as above; do applications have something
meaningful to do if they get an error back?

> For gtk_file_chooser_set_current_name, marked with two asterisks, should
> it check that the passed name has no path components in it, and is just
> a pathless filename?  This could just go in a g_return_if_fail() and not
> need a GError at all.

Hmmm, certainly intentionally passing in path components is a
programming error. But what if:

 - The user types in a path containing '/' in it
 - The file name isn't representable on the filesystem?

(*make_path)() has a GError return for this reason. Still, again
what would the application do in that case? A dialog about
some previously entered filename when the application goes to
pop up the filechooser seems very inappropriate.

In summary, the default answer is "no", but I'm willing to listen
to discussion as to why we should make the change now. It just has
to be convincing. :-)

Thanks,
	   			      Owen