Alarm code uses INPUT.Time and saves the time on an exit left or right.  Don't know what happens to a mode when power is hit, but I assume some sort of exit event occurs.  Annoyingly, the exit from input.time has to be handled by its callers, so this would possibly need code changing in everything that uses it.

or, update alarm time using onChange.  The problem here is that if you happen to move the time past the current time, and the checkAlarm function happens to be called at the same time, you'll get an alarm.

The trick here is that, while there would be an exit mode, it's controlled by the power off mode, rather than the alarm.  So, you could store modeParams when exiting INPUT.Time, but no ability to do anything with them.

again, if button modes were classes, alarm would simply be a subclass of input.Time for that case and the handlers would be built in.

Best to set for 'future' when the player ui can be overhauled, or 7.3 since there will clearly need to be some overhaul to browse the new db

James - IMHO we shouldn't target bugs/enhancements without assigning them. Somebody has to do the work after all.

Michael - very good point.  Having targetted bugs that don't have anyone working on it just clutters up the view of real bugs in process. Another in the long list of reason why I don't contribute any more.  Time spent more recently is far less productive due to the clutter. Far too many enhancements get targetted without a definition or approval.

Max this would be yours to address.

Dean, please give Max directions on how / when the alarm states should be saved.

Duh, I have no idea...  Michael?  Andy?  KDF?

Dean states "turning the knob or hitting any button should save the state"  It shouldn't be saved at just the end of entering a new alarm.

Here's an opposing viewpoint, someone who wants to be able to "cancel" out of setting/changing the time, and argues that saving the time on 'left' is inconsistent with the usual "player" UI: 
http://forums.slimdevices.com/showthread.php?t=57285

As I see it, one problem that Michael's GF is running into is the lack of visual cues as to 1) whether her change was saved/accepted and 2) how to save/commit her change.

What about something like INPUT.Choice where a radio or check box could indicate whether the time had been "saved", and provide a visual cue that the user should tap right-arrow or knob down to save the change? (In INPUT.Choice, an open radio button signifies "not chosen"; I'm suggesting that here it would signify something similar -- "not confirmed.")

Enter the time picker:
 8:00 am (*)
Start changing (not saved):
 7:00 am ( )
Tap right/knob (now saved):
 7:00 am (*)

Only 'right' would save the value and re-check the box. 'left' would cancel out and leave intact the last saved value. 

(In reply to comment #8)
>
> As I see it, one problem that Michael's GF is running into is the lack of
> visual cues as to 1) whether her change was saved/accepted and 2) how to
> save/commit her change .

There _is_ a visual cue.  The one that says 'Saving alarm...' that appears when you either move off left or right.

(In reply to comment #9)
> There _is_ a visual cue.  The one that says 'Saving alarm...' that appears when
> you either move off left or right.

Yes, you're right. She does not need a visual cue that her changes were accepted (they weren't), but that she needs to do something more in order to save her changes before powering off the player.

Moving to future for now, further discussion is needed before implementing any changes.