Haven't updated this TODO in a while, so I suspect it needs cleaning up,
but the most recent change I've decided I need to make is to leave the
cameras in charge of the download time. I finally have my own libgphoto2
code built into the program, so what I'll want to do is download the
images and delete them one at a time. If the camera leaves the USB
connection on longenough, I'll get them all. If it closes the USB connection
too soon, I'll at least get some of them, and the camera software
can give me more time next time if it see images left (still need
a lot of work on the SDM script to do that).

Yikes! I can grow the preview images, but if I try to shrink them, the
whole gui stays blowed up big and vast empty areas are introduced. Need
to figure out how to fix that... (I can manually shrink the window till
everything fits, so maybe I need to resize the main window somehow).

OK, I've been experimenting with making the SDM scripts and this linux
software like each other, and some things will work and some won't.

Here's what I think I actually need to do to get the most flexible
system running:

   1 - Fix the software so a short USB power pulse just takes a picture
       but doesn't expect to download anything.

   2 - If I click a checkbox that says download on next photo, then
       leave the USB power on after taking photo.

The SDM script, to accomodate this scheme needs to remember how many photos
it has taken since the last time the USB was left on for download, it can
then do a download_images_for N where N is computed based on number of
photos.

The linux software will also be tracking this number and will know how long the
camera will be willing to run the download, so it can leave the USB power on
just a tad longer than that.

The SDM script will need to poll the USB power until it actually goes back off
following the upload_images_for so that when it loops back to the top
it won't start taking unexpected pictures until the linux software actually
triggers the USB again.

It would sure be convenient if I could decrypt enough of the gphoto2 calls
to build them into the software rather than invoking gphoto2 as a subprocess.
I'd like to download and delete one image at a time until I'm finished with
all of them, or the clock is about to expire on the time I know the camera
is download for.

To implement this, I need a completely different scheme. Instead of a
simplistic script running everything at once through the UK1104, I need
a schedule of when things should happen so I can schedule lights separate from
USB, etc, then have timers go off to fire the events when they should
happen.

OK, I have the code in place for the new style program running, but I need to
actually fill in the body of the Scheduler class with actual code.

To do that, I'll need a global USB lock so I don't try to fire separate
events that need the USB bus at the same time.


Real Config dialog and save/restore code.

   More config data to deal with:

   Size of the preview images. [sorta done, but shrinking don't
   work too well - see above].

   filter pattern for preview images (OK, I added it to config).

   Add config for identifying the UK1104 by udev properties. Also add check
   for the 2 character ID in case you actually have multiple of these
   things. [ID code is in config, but not yet checked in the code].

   Add initialization for UK1104 to config, add configuration for which
   input is the mouse button. [In config, no real code for checking button
   yet].

Add more error detection.

Launch external apps on image file?

Hooks to run when images downloaded?

Delete images so you can snap same pages again without adding dups?

Rename images in sequential order (odd in left dir, even in right) after
downloading via gphoto2?

Change browse button sensitivity based on position in file list?

Add code to poll UK1104 for button push on digital input. [The low
level polling works, but I needs to actually make it run the camera now].

Check and see if I can just leave USB power on to both trigger photo and
download images (I think with the sync_off stuff this would work).  Perhaps
even allow batching under control of the computer - a long click switches to
USB mode for N seconds (where N depends on number of images) and a short
click just takes a picture and doesn't switch to USB mode. Can SDM notice when
USB power is removed and leave USB mode that way? Would be cool if it could
simply stay in USB mode as long as the computer leaves the power on - that
way I wouldn't need to worry about timing on the SDM side of he world.

Gather log info from libusb, running gphoto2, etc. and add to a log
window that cam be popped up.

Done:

Mode to tie directory browse buttons together so you can move through
images in both directories with one button click? [did that]

Fix bug - gphoto2 pukes if dup name exists (found --force-overwrite option)

Fix bug - assert if no images in image dir (checked for empty list).

Add image name to label over image. Done.

Add forward/backward/first/last buttons for scanning through images in the
left and right directories. (Got buttons on screen, need to hook them up
now). Now hooked up buttons as well.

Fix bug when unplugging UK1104 device (infinite read loop instead of
noticing EOF :-). I don't assert anymore if UK1104 is unplugged at startup,
but I haven't fixed unplugging it later yet. [Now I have].

Use udev stuff to notice when UK1104 is plugged in and to scan for it at
startup (so user doesn't have to specify /dev/ttyACM0 string).  (Looks like
udevadm-trigger.c has the code to copy that digs out udev
devices). Enable/disable Click button based on UK1104 status.

Both the above were fixed at one swell foop. I now find the tty device
from udev and don't need it in config anymore.

Add code to time how long it takes to fetch photos so delays can be
tweaked in the SDM script. (Did this, but times appear erratic, I guess
the best I can do is come up with some worst case times after trying
several examples).

Running the take picture cycle several times shows that the USB commands are
not 100% reliable. Need to send command, then check result to verify and
retry if necessary. (Or maybe send command twice or maybe both :-). Also got
just one ":" once in prompt. Need to fiddle with timeout and retry so I
don't get stuck. Since all the traffic is going through the same hub,
perhaps it would help if I didn't try to run two copies of gphoto2 and
fiddle the UK1104 at the same time. (Spiffed up the command runner quite a
bit to validate relay commands and send corrections if the first command
didn't work - also added retry on timeout for commands that are safe
to retry).
