135558 - [RFE] Sound alarms on per alarm basis

Status: RESOLVED DUPLICATE of bug 718419

(Calendar :: Alarms, enhancement)

Description

[xyzzy]

Right now, (April 4 XPI) the alarms are controlled by a global preference for
whether or not they should play sound.  I'd like finer-grained control for
individual alarms since some don't merit a sound and others do.

The UI for this should be accessible while setting the alarm, and have a
preferred default.  I would recommend converting the current pref to this
default preference, as it would no longer be required.

Comment 1

[Mike Potter]

That's a good idea Mike.
I am 99% sure that the ical standard allows the user to set whether or not 
to play a sound when the alarm goes off, and what this sound should be.
I'm sending this bug to Mostafa.  We need to implement the backend for 
this first, and then I'll put the front end in.
I think a checkbox on the add / edit event screen should do it for now, this 
will allow you to turn on and off the sound alarm for that event.
The global preference can be moved to one of two things:
1.  Disable all sounds.
2.  Default for adding events: sound yes or no?
Mostafa:  We can talk about this tomorrow.

Comment 2

[ajbu]

This needs the VALARM ACTION property.

see also bug 141406

   When the action is "AUDIO", the alarm can also include one and only
   one "ATTACH" property, which MUST point to a sound resource, which is
   rendered when the alarm is triggered.

Comment 3

[Matthias Buecher]

Just make sure if the sound of a download event isn't available, that you
fallback to the default sound.
Please see bug 135593 in conjunction with this one.

Comment 4

[rpe2101]

Please make sure that the fine-grained alarms can do more than just play a sound, namely run a script.

Comment 5

[Matthew (lilmatt) Willis]

Reassigning all automatically assigned bugs from Mostafa to nobody@m.o

Bugspam filter: TorontoMostafaMove

Comment 6

[mguessan]

When Lightning/Sunbird receives an iCal created event, it contains an ACTION:AUDIO alarm with ATTACH;VALUE=URI:Basso

This URI is obviously not available, but we should fallback to default
user defined sound (as stated by Matthias).
Note: this is the behavior under Lightning 0.9

Just a quick fix to at least enable fallback of ACTION:AUDIO alarms to default user defined sound:

--- calendar-js/calAlarmService.orig.js	mer. nov. 18 15:23:41 2009
+++ calendar-js/calAlarmService.js	mer. nov. 18 15:23:56 2009
@@ -383,8 +383,8 @@
         for each (let alarm in alarms) {
             let alarmDate = cal.alarms.calculateAlarmDate(aItem, alarm);
 
-            if (!alarmDate || alarm.action != "DISPLAY") {
-                // Only take care of DISPLAY alarms with an alarm date.
+            if (!alarmDate || (alarm.action != "DISPLAY" && alarm.action != "AUDIO")) {
+                // Only take care of DISPLAY and AUDIO alarms with an alarm date.
                 continue;
             }
 
--- calendar-js/calAlarmMonitor.orig.js	mer. nov. 18 15:21:37 2009
+++ calendar-js/calAlarmMonitor.js	mer. nov. 18 15:21:56 2009
@@ -109,8 +109,8 @@
      * calIAlarmServiceObserver
      */
     onAlarm: function cAM_onAlarm(aItem, aAlarm) {
-        if (aAlarm.action != "DISPLAY") {
-            // This monitor only looks for DISPLAY alarms.
+        if (aAlarm.action != "DISPLAY" && aAlarm.action != "AUDIO") {
+            // This monitor only looks for DISPLAY and AUDIO alarms.
             return;
         }
 

Thanks :-)

Comment 8

[mguessan]

I don't entirely agree this is a duplicate: the above patch does not implement full action support, the goal is just to play default user defined sound with iCal created events.

Note: this was the behavior under Lightning 0.9

Comment 9

[Philipp Kewisch [:Fallen] [:📆][:🧩]]

Yes, but the duplicate bug should also fix this issue.