It would also be possible to handle this through press/motion/release
event handlers, though GtkGestureDrag is more convenient for hacking in
support for dragging to widgets not supporting GtkScrollable (yet).
There may be some undesired interactions lurking, besides the jarring
movements when dragging native GdkWindows (these are a pain).
And store all direct thumbnailer output in the browser's cache--
low-quality thumbnails will always be regenerated, as is desired,
and we'll reload faster on devices where we don't store thumbnails.
This change improves latency at the cost of overall efficiency,
seeing as images with thumbnails will be spent cycles on twice.
Keeping this out-of-process avoids undesired lock-ups.
Moreover, embedded thumbnails can be fairly expensive to decode.
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.
This will speed up sort changes, as well as simple reloads,
at the cost of an extra hash map from URIs to Cairo surface references.
It seems unnecessary to provide an explicit option to flush this cache,
as it may be cleared by changing either the directory or the current
thumbnail size.
They fell back to gdk-pixbuf, then misrendered in the thumbnailer,
and crashed the program when loaded directly.
The second best we can do is scale them down, right after tiling,
which is a complex feature to add.
At least the left and middle mouse buttons seem to behave similarly
in other programs and systems.
Context menus are opened on button release on Windows and with some
GTK+ widgets (popovers in GtkPlacesSidebar).
The late, global gtk_widget_show_all() made it always start visible,
in particular when the program was launched directly on an image file,
and not in browsing mode.
