May be related to bug 10524?

Using SC 7.4.24762 r3945, verified behavior on my unit also. Additionally want
to report strange behavior when using the Controller to Pause unit. WebUI has
correct icons and behavior. Using IR remote from SB3, behavior as expected.
Using Controller to Pause unit causes unexpected behavior. Instant Clock
Screensaver and when the display is touched to reveal the Player UI, the Pause
Bar Icon is present instead of the Play Arrow Icon.

The "pause to 'when stopped' screensaver" behavior is by design for the
controller, but may or may not be the best behavior for a touch interface. The
IR (hide the SS) behavior was not intentional. It will be changed to match the
"pause to 'when stopped' screensaver" behavior.

We have a couple options than Ben/I discussed thinking about the touch
scenario:

1) for touch, keep the "pause to 'when stopped' screensaver" behavior - Pros:
is consistent with pause coming from IR, controller, web ui, etc.  Cons: Users
may want to quickly unpause after they paused, and they would expect a way to
do that to still be there a few seconds after they paused via touch.

2 After a touch pause, close the SS and switch to the now playing screen. Pros:
will still give them player controls when the come back to unpause a short time
later. Cons: will shift the screen contents a bit from now playing SS to now
playing screen which may have a different skin. Also, the stopped screen saver
may kick in anyway if their SS timeout is low, though users can increase the SS
timeout to avoid that.

A related problem is how to keep the number of touches required to unpause a
song to a minimum. Currently if a stopped SS is active there are 3 touches
required to unpause: 1) to unhide the SS, 2) to select NP, 3) to touch the play
button. This seem like too much clicking to "get back to the music".

One thought that addresses both areas is: Keep the original behavior as
described in 1), but when the user is within touch range (using the proximity
sensor) while any SS (other than the NP SS perhaps) appears, mini player
controls appear above the SS window. These mini-player controls would disappear
when either a) the SS hides, or b) the user leaves touch range.

One could even then have the NP SS not even have player controls until the user
is in touch range, which would give more real estate for content.

Touching the screen (or sending an IR command) should reset the screensaver timer. That means to me that the paused screensaver shouldn't kick in for 30 seconds (or whatever the timing is).

A touch (or proximity detection) should wake the screensaver.  If the music is playing, then you should be on the NP screen.  If not, then the screen should jump back to the last place that was navigated to.

Does that cover the cases?

Adding more background info (and some opinion :) )

(In reply to comment #4)
> Touching the screen (or sending an IR command) should reset the screensaver
> timer. That means to me that the paused screensaver shouldn't kick in for 30
> seconds (or whatever the timing is).
I originally thought the bug poster's behavior was a bug I had introduced during my action/event changes, so I looked into this, but I found that currently, an intentional design decision, if I understand correctly, was made to have the stopped SS appear if music is paused while the SS is active, from whatever source the pause came from (controller, web ui, etc). 

With the NP SS for fab4 and desktop, we then added transport and volume controls onto the SS window, so we alter the default SS "touch to hide" behavior for those buttons so they can work directly from the SS.  

>If not (playing), then the screen should
> jump back to the last place that was navigated to.
This would then be three touches to unpause, no? I think we want to have at most two touches to get music going from any screen. I just came up with that principle (fits with keeping the focus on music playback), not sure if others agree. 

>A touch (or proximity detection) should wake the screensaver.  
>If the music is playing, then you should be on the NP screen.
Sounds good, though deactivating a SS on proximity might not work out so well: Consider the Flickr SS. I see a nice picture, so I want to go up and see more detail. Having it go away would be a disappointment. 

If we agree to the "at most two touches to unpause music" principle, then its hard for me to see a way to avoid either 1) temporary transport controls on the SS window that appear on proximity or first touch, or 2) always going to NP after deactivating the SS (even when music is paused), or less likely, 3) always-on transport controls on all non-SS screens. Relying on proximity might help, but with all these scenarios, I fear proximity "intent" will be hard to discern giving the diverse usage scenarios, so I think we might want to contingency plan for not relying on it.


Having cancellable mini-transport controls appear above the SS window on proximity (or maybe even first touch if correct proximity proves difficult to achieve) keeps the focus on music playback at the cost of some annoyance for users that have no desire to see the transport controls at the time. If we do the first touch brings up mini-transport controls, second touch (outside the transport control buttons) leaves the SS, the downside is forcing two touches to leave a SS, though it would become second-nature to users that to quickly leave a SS that one needs to "double-touch" anywhere on the SS where the mini-transport controls won't appear, one touch to bring up the transport controls, the second touch to deactivate the SS.

Well, I already have a problem with the flickr screensaver because it's not really a screensaver since it's interactive.  

Ignoring that particular problem for a second, assuming we wake up the screensaver (proximity or touch), then unpausing is a maximum one touch to get to the NP screen and another touch to unpause.

Keep in mind that if you paused the device on the NP and walked away, then when you came back you'd still be on the NP screen, so it's one less touch.

Let's give this a try and then tweak to improve and don't get too hung up on the current controller behavior.

One more note: you are right to be worried about how well the proximity detector will be, this is unknown territory.  Think of it as a faster/automatic way to get an initial touch on the device so it comes out of a screensaver and switch to touch mode.  (Heck, waking from a screensaver with a simple touch doesn't even work well now!)

Time to iterate!

This has turned into a discussion of how touch screen pause should work from a user's point of view.

But there is currently a bug in the implementation that I suspect is in a lower level of the code than the user interface.
Why does the pause behavior depend on how long fab4 has been playing before pause is pressed?

(In reply to comment #7)
> This has turned into a discussion of how touch screen pause should work from a
> user's point of view.
> 
> But there is currently a bug in the implementation that I suspect is in a lower
> level of the code than the user interface.
> Why does the pause behavior depend on how long fab4 has been playing before
> pause is pressed?
> 

I think that might be the current as designed behavior, given the bug description. In the "after just a short period of time" case, I assume the SS was not on when the music first begin and that the NP window is up. If so, then there will be the standard x second timeout period before the NP screensaver will kick in, during that time, if the NP window (not the NP) is up, then it will act as normal, but as soon as the NP SS kicks in, the "pause to Stopped SS".  Note that the NP SS looks just like (or exactly like) the NP window, so it isn't obvious when the NP window switches to the NP SS.

Thus the discussion became about whether this "paused to stopped SS" is still the desired behavior for fab4. 

I made some assumptions about how the bug situation happens, which may have been false.  Could someone give more detail to the "When pressing pause on touch screen after just a short period of playback" case?  Especially, does the "after just a short period of playback" happen when the SS was already active (which I can't reproduce and which would certainly be a bug) or is this just a case of waiting for the SS to kick in? 

How do I determine if in plain NP or NP screensaver?

(In reply to comment #9)
> How do I determine if in plain NP or NP screensaver?
> 
It's very hard to visually see the switch since the windows are identical.  You can set applets.screensavers debugging on the fab4 to DEBUG, which will show when the SS is activated.. 

You are right.
If I set Now Playing screensaver to None, and use the plain Now Playing screen to control the player, I get consistent pause behavior.
I find it confusing that the NP screensaver behaves differently from the plain NP screen.

One bug is that the state of the play/pause icon is not synchronized between NP screen and NP screensaver.

(In reply to comment #11)

> One bug is that the state of the play/pause icon is not synchronized between NP
> screen and NP screensaver.
> 
Agreed. I think we might defer addressing this icon issue until we have resolved the overall NP behavior, unless Ben feels like jumping in. 

*** Bug 11117 has been marked as a duplicate of this bug. ***

*** This bug has been marked as a duplicate of bug 10351 ***