wperl is necessary to get rid of the console window,
which is merely one of several issues with the PAR Packer-based
ExifTool bundle used in the last commit.
The Perl installation could be heavily trimmed down,
but it seems to require a very manual process.
- Fix launching of subprocesses (missing gspawn helpers).
- Discard unused GSettings schemas.
- Make the program find its user guide.
- Bundle a somewhat suboptimal version of ExifTool.
It doesn't make a lot of sense to be able to toggle invisible widgets,
so just make F9 toggle "the toolbar that can currently be seen".
The more permanent setting can be adjusted in GSettings.
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.
There is also an alternative WcsGetDefaultColorProfile() path
that might be necessary on some broken versions of Microsoft Windows,
which I certainly do not want to support.
Windows and Linux applications are more likely to not bother,
and their desktop environments don't place windows right in the corner,
which is what happens with GTK+/macOS.
Linux has st_mtim (and an st_mtime macro),
macOS has st_mtimespec (and an st_mtime macro),
Windows has just st_mtime.
GFileInfo would be another option, though it seems unnecessary.
