> Strange that the fallback alarm mechanism is tied in with the Radio > popup alarm display/control. There should be distinction between the UI > (which may need to adapt for different types of player), and the alarm > functionality.
It's OK to have that distinction, the main problem is then to define events where the AlarmApplet stops checking if the audio is playing (and starts the fallback). If you have a popup it is easy: whatever (controllable) means there are to close the popup - the the audio checking can be turned off. Without a popup there are dozens of events where you had to decide if it stops the 'keep alarm going' mode. I'm not sure if 'every event stops this mode' is the right answer (as this include server events that could come alone ?). Maybe 'every user interaction stops this mode' is the right answer - but I don't know if thats doable (at least not by me, as I don't know enough) > The other suggestion of having alarm timeout = 0, such that music starts > without entering alarm mode, then obviously no fallback mechanism is > required, because it's not in alarm mode, instead it's in now playing > display mode, and displays the NP screensaver. No fallback mechnism means: if the server goes off one second after alarm time, your music will just play one second (and you might miss it). If people are aware of this ? > but whilst testing a few alarm scenarios Please wait and retest today. This night the new firmware was pushed for 7.4.2 and 7.5 with all the changes Ben did. > I just wanted to ask (bluegaspode?) whether the code changes that have > been proposed to open this up to 3rd party apps cater for both the > above. Sounded to me like it was just to allow alternates to the > alarm-menu, so only deals with the first point. There are no current code changes proposed (I'm hoping to find time, but am not sure). But you are right - if I had time the integration would only go as far as making it possible to change the alarm popup. Snooze by the way is no special mode (I think). This is just one more scheduled alarm some time ahead. Anyway: I think your points are valid and I would support them (though I don't know how difficult they are to implement): - when snoozing or stopping radio should revert to the state it was before - there should be some indication when snoozed (at least I could think of a small female voice hissing 'SNOOZE ACTIVATED' the moment you enter Snooze mode) *G* -- bluegaspode 1x SB-Controller+Receiver (Duet), 1xSB-Boom. 1xSB-Radio Server (7.4.1) running on SheevaPlug (Ubuntu) with attached Western Digital MyBook Essential. Secondary 7.4 Server on Debianized Buffalo Linkstation LS-CHL. ------------------------------------------------------------------------ bluegaspode's Profile: http://forums.slimdevices.com/member.php?userid=31651 View this thread: http://forums.slimdevices.com/showthread.php?t=73211 _______________________________________________ Radio mailing list [email protected] http://lists.slimdevices.com/mailman/listinfo/radio
