Bugzilla – Bug 14970
Possibility for third party alarm popup/screensaver
Last modified: 2011-11-06 23:23:30 UTC
By looking at the code it looks like the existing AlarmSnooze applet is resident and subscribes on events and when the alarm state changes it opens itself. This makes it hard or impossible to make a third party version which shows more information. It would feel better, if it was possible for the user to select which alarm snooze applet he/she likes to use, in the same way as he can choose now playing screen savers. As an alternative it would be good to at least make it possible for a third party applet to register itself as snooze applet instead of the default one. I can see two possible solutions: 1. Make it possible for the user to select among a number of alarm popup/screensavers (where only one or a few is available in the default installation) 2. Make the AlarmSnooze applet offer a service which other applets could call to make it call their function instead of the openAlarmWindow function when an alarm is triggered. The second solution is probably easiest and would satisfy the needs unless there are plans to introduce a more generic alarm screensaver concept similar to what we have on the classic players. Let me know if you don't have the time and the second solution is acceptable, in this case I could try to create a patch for it.
I agree that option 1 would be a better long-term solution, but for the short-term (7.5.0 release), I'd like to start with option 2. I made a patch that may either "just work" or can serve as the start for what you have envisioned. I'll attach it here.
Created attachment 6270 [details] patch to add registerAlternativeAlarmWindow service method this could be expanded to include method args, but at a basic level I think this should work.
Created attachment 6277 [details] Test applet to verify patch The attached AlarmSavers-0.1.zip file is a sample applet that takes advantage of the patch and allows any screensaver to be used as the alarm snooze popup. Of course, standard screen savers usually don't have any possibility to hit snooze or alarm off so a real third party applet specifically written to act as snooze popup will work a lot petter. But it's a sample that shows that the concept works and you can turn off the alarm by hitting the "off" button. YOur patch works good enough as a temporary solution, but some improvements to consider follows below. Some improvements to consider: - I wonder if the call to self:_setWakeupTime('none') would be better to move from _openAlarmWindow into openAlarmWindow, this way all third party applets doesn't have to do the same thing. - The fallback if-statement inside _openAlarmWindow might probably also be suitable to move out to openAlarmWindow. Or as an alternative, offer it as a service.
After reading all of the ideas in the forum (http://forums.slimdevices.com/showthread.php?t=73506) I think 'outsourcing' of the alarm-popup to third party devs would make a lot of sense. For Touch and Controller (and most Radio users) I guess the current (menu-based) implementation is very good. From the forums I see that there will be at least the following good alternatives which could be implemented by 3rd party devs if this patch is implemented: - having no alarm popup at all (directly going to 'now playing') - having a popup without menu (but bigger time display) making just use of the Radios buttons. - different sub-styles for button assignment (Volume Press/Big Button Press/Turning Wheel Left-Right) ... I reviewed Bens patch and erlands comments and want to support erlands idea to 'move up' the two common functionalities (setWakeUpTime + fallback-if statement) so that this code doesn't need to be copied by applet developers. Furthermore I want to propose changing the service signature to: registerAlternativeAlarmWindow(self, displayName, applet, popupMethodName) This signature imitates the screensafers API (addScreensafer) so the usage pattern stays the same for 3rd party devs (without making the implementation more complicated for Ben). The displayName argument would be ignored in the first implementation. Later on the displayName could be used to: - register more than one alternative alarm window - let the user choose an alternative alarm window for each alarm (solution #1 from erland, see first post). This API would be stable for the current solution #2 and later solution #1.
Moving Matt Weldon bugs
There is a current working patch (for 7.5) from erland in his repositories: http://erlandapplets.googlecode.com/svn/PatchInstaller/trunk/patches/CustomAlarmWindow/CustomAlarmWindow-1.0.patch Some comments/suggestions about this one: - I still propose to change the way applet-devs register their own windows to be like it is done with screensafers: 'registerAlternativeAlarmWindow(self, displayName, applet, startAlarmVisualisationMethodName, stopAlarmVisualisationMethodName)'. AlarmSnoozeApplet will actively call the 'startAlarmVisualisationMethodName' (instead of calling a service). See my last comment about 'displayName'. - the 'startAlarmVisualisationMethodName'-callback (or service) should be given the type of alarm ('rtc' or 'server'). The reasoning: on an RTC alarm I might want to warn users, that subsequent alarms might fail. - there needs to be a seconds callback 'stopAlarmVisualization' or alike. This needs to be called in notify_playerAlarmState() where currently there is just a call to hide the original window (right in the beginning of notifiy_playerAlarmState ). This is needed, because sometimes the server stops the alarm. - there should be some documentation on what 3rd party devs have to implement so not to unknowingly get in danger of sacrificing the alarm reliability. Most important point is: - the devs MUST ensure, that either alarmOff or alarmSnooze will be called when their alarm visualization disappears, otherwise the internal state-enginge of the SnoozeApplet might get confused and miss subsequent alarms.. The easiest way to achieve this is to do it like the AlarmSnoozeApplet using ----------------- window:ignoreAllInputExcept( --these actions are not ignored { 'go', 'back', 'power', 'mute', 'volume_up', 'volume_down', 'pause' }, -- consumeAction is the callback issued for all "ignored" input consumeAction ) ---------------------
Unassigned bugs cannot have a priority.