SDL backend doesn't have a box-restore function implemented yet. Also,
pop-up dialogs look weird in high-colour modes (e.g. try `:' when
viewing a pic in 24-bit mode) and are screwy in 8-bit modes too when a
palette-change is needed, and GIF animation doesn't seem to work. The
SDL backend has other problems too, but these are the main ones.


The TIFF reader could do with progress reporting. Unfortunately, the
TIFF format and libtiff combine to make this a total pain to do in a
sufficiently general manner without killing the loading speed. Maybe I
could try reading line-by-line with progress report, then resort to
no-progress read-at-once if it can't be read that way? Even for the
line-by-line case we have the not-abortable problem - but bearing in
mind that the hffunc would only be called at a well-defined time
outside of all libtiff functions, it should be possible to close
things down cleanly.


It would be nice if the smaller/bigger mode keys ([,]) worked in the
selector too. Could even use the same code to do it
(change_mode_size() in vgadisp.c) if hacked slightly (would need to
remove dependence on pixelsize, effectively 1 in the selector).


The (concept) indexing of Invoking zgv is weak at the moment -
everything's at the top of the node, when most of them should go next
to the thing they're indexing.


Recursive updates don't honour the fs-slow-thumbnail-update setting
across directories - that is, they jump to the first file which needs
changing. But frankly, this is a feature not a bug. :-)


I suspect the small italic font isn't being used any more; should
check, and get rid of it if so.


The file details dialog doesn't look so great if the old line-based
text is enabled. But I'm probably going to drop the line-based text
soon, so I doubt there's much point trying to fix this. :-)


readgif.c should cope with files with more than 256 images.
(Technically it does *cope* with more images, but it doesn't load
them.)


If you specify selector colours (with the col-* options) which don't
differ by very much, and thumbnails are being displayed, then the
differences disappear entirely and only one of the close colours is
shown.


Should probably have right-button-menu options for GIF animation,
auto-mode-fit, and smaller/bigger mode.


It might be nice to have a further `act like xzgv' option for reversed
mouse movement in the viewer (dragging the picture around, rather
zgv's dragging the screen around). But probably tricky to get the feel
right, given the lack of a mouse cursor when doing it.


Copy over any handy build changes from xzgv. Most already dealt with,
but the stuff about /usr/local/info/dir in config.mk hasn't been, nor
has doc/Makefile been changed to use gzipped info files and chmod a+r
the dir file (important if install-info created one from scratch, for
example).

Also, consider making /usr/local the default installation point. This
would be hairy as uninstall would then have to blast any possible zgv
installation under /usr as well, but I think it's the Right Thing to
do.


Mouse support isn't really finished - the goto-dir dialog should have
ok/cancel buttons, and currently you can't interrupt file loading and
thumbnail updates. The latter two would need a custom mouse event
handler temporarily installed, so that we could avoid losing any
clicks. Actually it might not be too bad an idea to always use a
custom handler; that would be easier. After all, on a slow machine you
can already lose clicks during a file-selector screen redraw!


File move should probably delete any existing thumbnail for the file
if the file itself is moved successfully.
