Bugzilla – Bug 649
Allow Assignment Of Screensaver For Off Mode
Last modified: 2008-09-15 14:37:04 UTC
Create a method to optionally assign and allow a screensaver to run in the "off" state. This may (or may not) be a different from any defined for use during the "on" state. This would allow for the display of something other than the "day, date, and time" when the unit is not being used.
*** Bug 650 has been marked as a duplicate of this bug. ***
Would this be a screensaver when off, or a different display entirely when off? The first case would be relatively simple, except when turnign off the user would see the date/time until the screensavaer kicked in. The problem, however, is that the server often checks whether or not the server is in 'off' mode. The screensaver would not be 'off mode'. The second case gets rid of the date/time, avoids the mode problem but I can't see it being easily implemented since screensavers are not designed to simply be replacement display lines. I think the first option is the most viable, but it does mean removing all tests for $mode eq 'off', changing then to check $client->power instead.
I apologize, but I am a wee bit confused by the "server checking the server" and the "screensaver would not be 'off mode'" comments. If the server is off how can it check to see if it's off? Or do you mean "off" as in nothing is playing on any clients? My confusion notwithstanding, my vote would be to enable screensavers when the client is "off" so the existing pool of screensavers can be used (your comment "screensavers are not designed to simply be replacement display lines" implies that they would not function if the alternative development path was chosen). Of course, I am clueless as to the implications of removing all tests for $mode eq 'off' and replacing with a check for $client->power so I don't know if that's good-bad-indifferent.
Just thinking about Vidur's comment in the lists about having a "player time out to Now Playing if it is playing audio and a screensaver if it is not playing audio." There was concern expressed that this had been done before and reversed by user complaint. I can understand that. As an alternative would it be possible/desirable/easier to split the existing "screensaver" function into two separate parts, idle vs. non-idle? That is, give the user 2 choices in player settings instead of the current 1. For example, a user could set Now Playing while listening but have LineX on when the client is idle. If a user wanted existing behavior, the choices could be set accordingly (perhaps by default). If this functionality were available I would probably never turn the unit "off" since the only reason I currently do so is to save the display.
miguel, it was not inteneded to make sense to you. its developer speak. were I to make a patch for this, it would be pointless wihout having some decision from Slim Devices as to which directions to take. The server would degrade into crap if the architecture went undirected. The main point is whether the 'power off' mode now becomes a choice of displays, or simply displays date/time until the screensaver timeout occurs. screensaver during idle/vs playback is rather out of the scope of this particular bug item. if it were my opinion, 3 different screensvaer settings is a waste.
nevermind abotu $client->power. it relies on $mode eq 'off' as well. an off screensaver is going to need a new framework.
a little bit of history: Originally, the screensavers were ONLY for when idle. While playing, the "NOW PLAYING" display functioned as a screensaver. Squeeky wheel comes along, and 'now playing' is only an option. Screensavers would henceforth kick in regardless of playback as long as the player was not in 'off' mode. As the screensavers, each, are modes of their own, having a screensaver is 'off' mode is by definition impossible. The screensaver would move the player out of 'off' mode, into the screensaver mode. Thus, all current tests to check if the player is off would be broken. While its possible to change this, all plugins that do the same tests would be broken too. It is not a simple thing to arrange for all plugins to be fixed as this relies on users to download the updates themselves. Many do not, and end up coming to the list to complain about a 'serious problem' that can take up a lot of support time before anyone realises they have a broken plugin. 'off' mode pretty much has to stay as 'off' mode. one possible way to work within this, is to find a way to refer to any existing screensavers' dislay function (lines()). If so, we can simply replace the off linefunc with the chosen screensaver's function. The catch here is that some screensavers arent just displays. TinyLittlePacman has a button set all to itself, thus it would be broken if chosen for 'off' screensaver. of course, 'off' mode is also a total fake. The player is not really off, so perhaps there could be a way to go into a screensaver mode, but still have it labelled as "off" mode as far as anything else is concerned. This would involve overwriting the 'off' mode parameters with those of the chosen screensaver. This, of course, breaks if any screensaver plugin is later removed. Some sanity checks would have to be in place inorder to restore the normal 'off' mode if this were to ever happen. Other option, as touched upon in a few cases is to leave 'off' as 'off'. If you want RSS feeds when 'off', just set the screensaver to 'rss feed' and leave it alone. it will go into that mode after the timeout (tell yourself its automaticaly turning off, if you have to). When the player is actually playing a song ....well, personally I dont know why "now playing" isn't the only choice, but there could easily be a setting to use only when there is curent playback. Maybe this will mean more when the visualiser works. This way, a now playing screensaver could be a fullscreen spectrum display. The problem is, 'off' still exits and people will always want to 'power off' their player and will likely not be happy that the clock is the only display. Maybe 'off' should just be a client pref, letting the mode be user selectable.
So perhaps the realistic solution here is to simply allow the user to specify a "Now Playing" screensaver and an "Idle" screensaver, with the understanding that NO screensaver (other than the clock) is available in Standby (or "OFF") mode. I can't speak for anybody else, but other than the psychological effect of turning the player off, I really don't care what mode it's in as long as it's doing what I want it to do.
"Off" should just be defined as a shortcut to "Brightness off"
Created attachment 202 [details] create playback saver and idle saver This patch creates the options to set a screensaver during playback, and a screensaver during idle. off mode is unaffected.
Created attachment 203 [details] missed one string fixed a string that didn't actually need to be changed.
committed to cvs 18/11/04
*** Bug 667 has been marked as a duplicate of this bug. ***
There are 536 bugs in the database with targets of '---' that were fixed prior to new year 2006. I am setting them to targets of 6.2.1 to keep them from showing up in my queries.