Design Notes/ToDo for GUI

Capturing design notes and action items from initial GUI discussion, trimmed down a bit and brought up-to-date.

Non API - Graphics to-do list based on below (threeaxis):

New Icons for:

* ramping / not ramping

cc - is this really needed? will need supporting API call

* save settings
* save program
* select serial port
* engine connected/not connected

cc - I think threeaxis has already delivered this, will locate and put in data dir

* error image

cc - added to list, 'cos errors happen =)

Images Working on (threeaxis):

* Logo

Discussion notes about implementation:

Display OpenMoco logo on startup along with build version

* Maybe on a per motor basis allow for free movement (for returning/setting home position). Check best option:
* 2 direction button, just keep pressing til desired position
* 1/10/100/1000 steps choice buttons, 2 direction go buttons

cc - see new model in svn - what do you guys think of this? The distance type is carried over from motor selection, and the user would slide the slider to show how far to move with each move request, also added KF set button, to align with common workflow that threeaxis pointed out

* Visual feedback on selection(rectangle lighting up around selection) - would love if we could have static, active and hit states (if memory permits)
* Prevent erroneous clicks(time between touch events?)
* Screensaver (the Slide allows for 16 brightness levels, 0 being off, 15 full brightness
* Settings
* Verify version the engine is running alerting the user for an update if necessary (must check with Chris to implement this in the engine and the perl libraries). Maybe this can be checked on startup?

cc - definitely a low priority

* Save current settings on flash automatically(think remember program)
* Screen brightness

cc - n.b.: only useful for PDAs/touchshield

* Manual user setting
* Define screensaver on/off allowing for timeout selection
* Select motor/device (& setup motor scale - think steps per angle/steps per inch)

Please comment

Here's an API to-do list: (church)

Release 0.82 branch is branches/release-0.82 in svn, or here: http://openmoco.svn.sourceforge.net/viewvc/openmoco/OpenMocoComponents/TimeLapseEngine/branches/release-0.82/OpenMoco_Timelapse_Engine/

* Challenge/response protocol (is the device ready? listening?)
* added in branch 'release-0.82'
* 'shoot now' command
* added in branch 'release-0.82'
* can specify exposure time (32 bits) with request
* Backlash compensation for axis
* added in branch 'release-0.82'
* added backlash comp for each axis (up to 255 steps)
* Extended all keyframe counts to 16 (doubled number of keyframes)
* Extended actions to 16 (doubled actions)
* Extended camera keyframe shot count trigger from just over 8,000 to over 268 million
* Unfortunately, also reduced available mS for time keyframes in half (now about a total of 3.1 days of time available to trigger keyframes)
* Status request
* status of motor x
* enabled/disabled
* steps moved total
* position relative to home
* current 'max speed'
* ramping/not ramping
* up/down
* keyframes
* which keyframes have not activated
* camera
* current interval
* current exposure length
* number of shots taken
* is shooting now
* program
* current run-time
* started/stopped/paused

Discussion notes on above points...

* Manual motor controls - essential (that's why there's the move now instant api command, so you can position the axes. The worm gearing prevents any positioning by hand by moving the axes manually)
* It would be best to implement as 1/10/100/1000 (or degrees/distance... see below) as that is analagous to the API behavior. The constant thing would have to be hacked, and would be less reliable
* Visual feedback - nice and useful - lagniappe though.
* Erroneous clicks - definitely, although I think most screens would prevent it by re-drawing a new screen after click, for on/off flags, I could see this happening if the control loop runs too fast. Probably just follow standard de-bouncing techniques here?

cc - does not seem to be an issue w/ processing

* Settings
* Verify engine:
* I've already started to implement a challenge/response strategy in the API, it's a bit aways from being done, but as per our message the other day, it's going to require you to request availability before sending a command, and you could wrap a timeout around the request, as it should respond within a few seconds in worst-case scenario
* Save current settings - hmm. Would there be a conflict with 'save as program' outlined in the workflow? I like the idea though.
* Screen brightness - manual only, I have no more pins available =( I have most of the stuff ready for an external exposure control device hooked up via i2c, but that's a big expense for just controlling the screen brightness. (See 'lightrails')
* Screensaver on/off, yes
* Motor
* I don't understand 'connect to motor'? That was Jay's: read "select motor"
* Ahh, ok. We'll have to examine the term in concept, I'm still a little lost where we apply the statement... But, the connect to device is definitely important, it's how we're going to add external things run via i2c, like the external exposure control
* I would definitely like to see motors provided with scale..
* e,g,:
* if motor is a rotational axis (pan/tilt): steps/degree e.g. 150 steps/1 deg
* if motor is a linear axis (dolly, etc.): steps/in[mm or cm]
* Would probably need cue for scale type (linear or rotational) - would need the user to select -- radiobox style input?
* It should also allow the naming of axes, so they don't appear as '0, 1, 2, 3'. - i.e. name '0' as 'pan', and measure in degrees, w/ x steps per degree.
* i'd be happy to design a full keyboard but perhaps we should give a mulitple choice option? pan 1 dolly 1 tilt 1? new icons for each, instead of generic numbered motor? (threeaxis)
* We could do that - provide a list of options, but the 3rd and 4th axis would need special list of names? (dolly, truck, focus, whatever?) (cc)
* This should allow the user to put in "real values" instead of steps in things like movie mode and distance to move between shots, etc.
* I also think that this isn't the first thing necessary, so it could be prioritized lower than some other features

Just adding another possible feature that could be easy to implement:

* Movie preview
* When in movie mode, can preview key points (beginning, certain relative points in progress, and end) quickly:
* With length of movie given, shots, etc. use the 'move now' and 'shoot now' API commands to go to key points in the movie, take one shot, and move to next key point
* admittedly, 'shoot now' needs to be added to the API, but it would be very easy
* Key points could be defined as when motors start, stop, ramps start, stop
* Additionally, firing the camera where motors would be on motor keyframes would be very easy
* Extrapolating where elements would be on camera or time keyframes would be a little harder, but still doable
* This way you could determine in a few seconds if the movie will cause movements at the right points -- i.e., if I want to start tilting when I get to a tree in the scene or something