(In reply to comment #0)
> Is the Queen photo gallery app
> deliberately trapping the power button to redefine it as exit??

No, it's just a bug.

But why would you ever want to turn it off anyway? ;-)

Whew!

Richard: is this yours or ben's to look at

Tom, I think this is because the photo album is being treated as a screensaver?

Maybe we should examine the more general question also, since there is related behavior here.

Currently, any picture display is treated as a screensaver, since other than this new concern, SS's and slideshows work identically. This behavior could be changed.

The larger question:
SS's are disengaged by any key, including power. This doesn't include the NP SS, because it isn't a SS.  The reason power disengages the stopped SS is:

Power doesn't really mean "turn off" it means, "move to standby/sleep", which means "turn on the 'off' SS". In the off case, pressing power again leaves the standby mode and disengages the SS.

We offer users the ability to change the off and stopped SS's which makes our device different from, say, a VCR standby mode. Off/standby is really "stop music and engage a default or selected SS".  If they change the stopped and off SS to various things (like flickr for off and clock for stopped, for example), it won't be obvious when they come up to the device what to press to get back to using the device.  The device might be in standby, they can't tell unless they remember and told all other users of the device to remember "oh, when this particular screen is on you need to remember to hit power first". 

Now, users have a single, safe way (power) to disengage any SS, whether it be the off ss or the stopped ss. If you instead have power directly turn power off when the stopped SS is on, then users will have a frustrating time if they think its in the off state. They hit power and a different SS appears. Or, the other way, they think it's in the on state and spin the wheel, etc to no effect.

As another resolution, I would have preferred that the power off ss could be turned on by any press (if the power off SS is anything but the blank SS), but that was shot down.

Note: this behavior only affects users who have changed from the defaults. By default, there is no stopped SS.

Thanks, Matt. I'd like to add some more thoughts before your design meeting:

As a user, here's what I want/expect: If the device is off, pressing Power should turn it on. If the device is synced to another player that's playing something or I have the device set to resume playback, it should start making noise, and maybe also start showing the NP SS (which isn't really a SS??). Otherwise it should display my Home menu.

If the device is on, pressing Power should turn it off. That doesn't just mean switch to the When Off SS, it also means stop playing MySB/SBS music (I'm not sure about Line In; I could imagine some users wanting that always active). In this case, I started playing Queen tracks, started the photo album, and then wanted to turn the device off (stop showing pics and playing music). So I pressed the Power button, and I ended up looking at a SqueezePlay menu, still hearing the music. Sure, I only have to tap Power one more time to turn the device off, but this seems like a rather odd device not to turn off if it's obviously on & I press the Power button.

NP not being a real SS: 
"Now, users have a single, safe way (power) to disengage any SS, whether it be
the off ss or the stopped ss."

Except that doesn't include the NP SS, because the NP SS really isn't a SS?? If I'd tapped Home twice to get the NP screen and tapped Power, then Radio would have gone silent and switched to the off SS, right? Because the NP SS isn't really a SS (despite the language in Settings > Screen), and Radio can be turned off with a single Power tap from the NP SS.

If I choose another SS, maybe a 3rd party SS, for When Playing, would that behavior change because I'd be using a real SS?? 

Safely exiting a SS: I expect pressing the Back button to be a safe way to exit a SS. Back generally doesn't cause any actions (knob_down and action-specific keys like Pause and Preset_1 do). Home should also be a safe way to exit an SS.

If I had the same SS for When Stopped and When Off and the device was silent and I therefore couldn't tell if it was "on" or not, then Home or Back might do nothing if the device is off. If I tapped Home and nothing happened, I'd tap the Power button. This is pretty much what I've learned from earlier Squeezeboxes and other electronic devices: if navigation controls have no effect, then the device is "off" and I need to press the Power button (on my PC, I tend to tap the Shift key to wake the PC if I think the screen has merely shut off). Alarm and More might also be good choices, but not "action" buttons like Presets, Rew, Fwd, Pause, or Play. If I press an obvious "action" button like a numbered preset, I'd want Radio not merely to exit the SS, but execute the requested action.

"I would have preferred that the power off ss could be turned on by any press (if the power off SS is anything but the blank SS), but that was shot down."

That sounds like the behavior I reported in bug 14220 -- did you win that argument after all?

"If you instead have power directly turn power off when the stopped SS is on, then users will have a frustrating time if they think its in the off state. They hit power and a different SS appears. Or, the other way, they think it's in the on state and spin the wheel, etc to no effect."

How many users have the same SS for Stopped and Off? And how much of a problem is it if I'm confused, tap Power, and go from Stopped to Off? If I tap Power again, I'm at the Home menu and can use the device. Isn't it more important to let users go from on & playing to fully off with one tap? I think I hear a knock on the front door, so I try to turn off my playing Radio with Power and it doesn't shut up -- isn't that worse than a confused user in Stopped mode having to tap Power twice to get back to a menu? Isn't it more reasonable for individuals to use the Back button to exit SS, and to learn that if Back doesn't work, the device is Off and they need to tap Power? 

I'm a little concerned about the UI's predictability, which I clearly value highly, if buttons are supposed to behave a certain way when a SS is active and the UI labels Now Playing and Screen Off as SS choices but the button behavior is different there. I expect different button behavior in custom SS -- for instance, the SuperDateTime SS on IP3K lets me scroll through pages of info with Up/Down even though all the core IP3K SS modes totally ignore Up/Down -- but I expect more consistent behavior in the core code. I mean, I've written [IP3K] screensavers before, and I never would have guessed that NP on Jive was not a real SS!

Thanks.

I agree with Peter. 
I am using a (3.part) SS for now playing, and it is frustrating that i have to push the power-button twice to power off (or whatever you call the state where music stops and stand-by SS is showing).

If i want to disengage a SS (NP or Stopped) I will use the back or home button. In power-off mode, I only expect reaction from the power-button.

Thanks,
Thomas

Moving Matt Weldon bugs

I agree with Peter as well.  Pressing any key should not just wake the screensaver but also perform that function as well.  It is really odd behaviour to press the power button twice to turn the radio off.  Not only that, it makes it inconsistent behaviour.  If screensaver is not engagged, you only need to press once but if ss engaged, you need twice.  What if you have a programmable remote that does macro commands.  Do you program it to send once or twice?  Either way would not be right.

Unassigned bugs cannot have a priority.

The Queen app is long gone...