Created attachment 217508 [details] [review]
Don't mix file and URI related functions

g_strconcat ("file://", ...); is never a good way to create URIs
and most of the functions worked on local paths instead of URIs, so
use paths everywhere.

Created attachment 217509 [details] [review]
Fix crasher on exit with URI/path changes

Now that screenshot_build_filename_async() operates on path,
it will also return a path. Make sure the caller can handle that.

Review of attachment 217508 [details] [review]:

The only thing that doesn't fully convince me here is that AFAICS we lose the ability to save a VFS URI.
In interactive mode, we remember the last location used, and set that as the initial location for the next file chooser...does that work for remote VFS locations after this patch?

Review of attachment 217509 [details] [review]:

This should be squashed to the previous patch if we end up pushing it.

(In reply to comment #3)
> Review of attachment 217508 [details] [review]:
> 
> The only thing that doesn't fully convince me here is that AFAICS we lose the
> ability to save a VFS URI.
> In interactive mode, we remember the last location used, and set that as the
> initial location for the next file chooser...does that work for remote VFS
> locations after this patch?

I wasn't sure whether you wanted that.
In this case, it should be as easy as replacing:
+      retval = g_filename_from_uri (save_dir, NULL, NULL);
with:
GFile *file;
file = g_file_new_for_uri (save_dir);
retval = g_file_get_path (file);
g_object_unref (file);

You're lucky this didn't break before. screenshot_build_filename_finish() is randomly returning URIs or filepaths depending on which path it takes.

Merged the 2 patches, and made sure both sections could handle remote URIs, using GFile rather than g_filename_{to,from}_uri()