Re: Adding error reporting to GtkFileChooser

[Federico Mena Quintero <federico ximian com>]

On Wed, 2004-03-03 at 10:45, Owen Taylor wrote:

>  - Error out parameters could be added by duplicating the 
>    API
> 
>      gtk_file_chooser_select_uri_checked()

I wouldn't really like that; the filename/uri quasi-duplication in the
current API is cumbersome enough as it is.

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

Sure, here are some examples:

1. An aplication has an "Insert clipart" command.  When invoked, the app
brings up a file chooser dialog, and does
set_current_folder("/usr/share/fooapp/Clipart").  If that folder doesn't
exist, the app may want to bring up a dialog saying, "Clipart is not
installed; draw the images yourself".  Or it may want to fall back to
another folder.

2. An application remembers the last folder that was used in the file
chooser.  The folder goes away.  The application brings up the file
chooser again, and does set_current_folder(last_folder).  Knowing that
this failed, it can fall back to set_current_folder(g_get_home_dir()).

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

These are the unselect_filename/unselect_uri functions.  Maybe there's
no need to report an error for them; if the file or its folder no longer
exists, you don't care if it's selected or not.

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

In the file chooser's Save mode, you mean?  We should certainly make
that name relative to the current folder.  For example, I do this
operation very frequently:

1. Load a photo in the GIMP, edit it, scale it to a size suitable for a
web page.

2. Save the file in /foo/bar.

3. Scale the image to a thumbnail.

4. Re-save the file.  Since the current filename is already entered in
the file selector, and the latter is already in /foo/bar, I can just
prepend a "thumb/" to the filename in the entry to save in
/foo/bar/thumb.

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

Precisely; if ::make_path() reports errors, maybe set_current_name()
should do that as well.

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

/me brings out the industrial arm-twisting device.

  Federico