This makes use of our image processing capabilities in order to
turn arbitrary image files into normalized thumbnails,
upload them to a temporary host, and pass the resulting URI
to a search provider.
In future, fiv should ideally run the upload itself,
so that its status and any errors are obvious to the user,
as well as to get rid of the script's dependency on jq.
Implement a process-local VFS to enable grouping together arbitrary
URIs passed via program arguments, DnD, or the file open dialog.
This VFS contains FivCollectionFile objects, which act as "simple"
proxies over arbitrary GFiles. Their true URIs may be retrieved
through the "standard::target-uri" attribute, in a similar way to
GVfs's "recent" and "trash" backends.
(The main reason we proxy rather than just hackishly return foreign
GFiles from the VFS is that loading them would switch the current
directory, and break iteration as a result.
We could also keep the collection outside of GVfs, but that would
result in considerable special-casing, and the author wouldn't gain
intimate knowledge of GIO.)
There is no perceived need to keep old collections when opening
new ones, so we simply change and reload the contents when needed.
Similarly, there is no intention to make the VFS writeable.
The process-locality of this and other URI schemes has proven to be
rather annoying when passing files to other applications,
however most of the resulting complexity appears to be essential
rather than accidental.
Note that the GTK+ file chooser widget is retarded, and doesn't
recognize URIs that lack the authority part in the location bar.
It still needs no versioning, as it's not really used by anyone.
An alternative method of passing a "low-quality" flag would be
perusing fiv_thumbnail_key_lq from fiv-thumbnail.c, which would
create a circular dependency, unless fiv_io_{de,}serialize*()
were moved to fiv-thumbnail.c.
Přemysl Eric Janouch