fixup! [0000080] Added 'video' capability

Signed-off-by: Luke Stuyvenberg <stuyvenberg@wisc.edu>
fixup! Added an available-space indicator on acquisition

Signed-off-by: Luke Stuyvenberg <stuyvenberg@wisc.edu>
[0000079] Prompt for overwrite

If you select a directory with anything in it, the system will check to
make sure you want to write there.

Signed-off-by: Luke Stuyvenberg <stuyvenberg@wisc.edu>
[0000075] Hushed up stage out-of-range exceptions

Now it just clamps the destination to the acceptable range, rather than
returning an error so CMMCore propagates an exception all the way up to
Java.

Signed-off-by: Luke Stuyvenberg <stuyvenberg@wisc.edu>
[0000078] Tried to squish the GUI down a bit.

I forced the table to shrink somewhat -- it was pushing the height another
fifty pixels or so -- but the effect isn't huge...

Signed-off-by: Luke Stuyvenberg <stuyvenberg@wisc.edu>
fixup! fixup! Further revisions to OME-TIFF handler.

Signed-off-by: Luke Stuyvenberg <stuyvenberg@wisc.edu>
Fixed a crash on new/modify HW config

My fancy 'don't need to store velocity' approach to velX/Y properties
backfired -- MM was trying to get them before the motors had been
connected, I wasn't checking to make sure our motor handles were valid,
and finally, the Picard Industries API doesn't check to make sure the
handle is non-null either.

Signed-off-by: Luke Stuyvenberg <stuyvenberg@wisc.edu>
fixup! [0000078] Tried to squish the GUI down a bit.

Signed-off-by: Luke Stuyvenberg <stuyvenberg@wisc.edu>
fixup! [0000080] Added 'video' capability

Signed-off-by: Luke Stuyvenberg <stuyvenberg@wisc.edu>
fixup! Added an available-space indicator on acquisition

Signed-off-by: Luke Stuyvenberg <stuyvenberg@wisc.edu>
Extended motor range to be from 0 to 8000 (incl)

The motors actually support position 0 -- I think the only reason we roped
it off was the sticking troubles Dresden was having, but I think some
other changes I've made might wrap that up.

Signed-off-by: Luke Stuyvenberg <stuyvenberg@wisc.edu>
Added some null-handle checks in DAL

I was getting intermittent exceptions, but it turned out to be due to some
other experiments I had been running. Still, these barely cost any
execution time and can save a lot of headaches. ;)

Signed-off-by: Luke Stuyvenberg <stuyvenberg@wisc.edu>
fixup! fixup! [0000078] Tried to squish the GUI down a bit.

Signed-off-by: Luke Stuyvenberg <stuyvenberg@wisc.edu>
Various UI improvements & exposure slider fixed

I've implemented the rest of the code for the exposure slider and sped up
the slider updates.

Signed-off-by: Luke Stuyvenberg <stuyvenberg@wisc.edu>
Added support for our Cube in Madison.

We'll talk about getting the Dresden setup working ASAP (presumably
Monday). At the moment, the power range is falling back to defaults 0.05mW
- 20mW, but I'm working on that.

Signed-off-by: Luke Stuyvenberg <stuyvenberg@wisc.edu>
fixup! Added support for our Cube in Madison.

Signed-off-by: Luke Stuyvenberg <stuyvenberg@wisc.edu>
Finally patched autocalibrator

Apparently I never got around to restoring the fitting code after
committing the missing FitHypersphere.java.

Signed-off-by: Luke Stuyvenberg <stuyvenberg@wisc.edu>
fixup! fixup! Added support for our Cube in Madison.

Signed-off-by: Luke Stuyvenberg <stuyvenberg@wisc.edu>
[0000058] Auto-detecting Pi motors/twisters

When the DAL is initialized by Micro-Manager, it pings all motor and
twister indices between 0 and 500 (inclusive), storing each hit (each
motor/twister that connected successfully) in a list. This list is then
consulted by the stages and twister -- the first 3 motors will be assigned
Y/X/Z, and the first twister will be the rotation. If there are less than
3 motors or no twisters, those missing serial numbers will be replaced
with -1, but may be changed by the user (so long as they can initialize
the associated motor).

Signed-off-by: Luke Stuyvenberg <stuyvenberg@wisc.edu>