No way to enable alarm upon creation

In my opinion, rather than having the alarms being enabled automatically upon creation, there should be an opt-out option to enable the alarm upon creation.

I think it makes perfect sense to enable an alarm both upon creation and after it has been edited.

One approach would be to enable an alarm after the user has clicked the "Close" button on the "Edit alarm" dialog.

Unfortunately there are cases where the "Close" button is not clicked after editing an alarm:
1. Double click Alarm #1 and edit it
2. Double click Alarm #2 and edit it
3. Click "Close"

Should both Alarm #1 and #2 be enabled in this case?

Removed from 0.3.3 milestone because of lack of feedback.

Johannes, I believe that both alarms should be enabled in the case you describe. I may have alarms programmed for lunch breaks, meetings etc and most of the time I have several alarms enabled. The alarm on most smartphones operate in this way also, where it is up to the user to disable the alarm.

As I mentioned in my duplicate bug report 1003581, I think disabled alarms should be greyed out and active ones not to communicate the status to the user better.

Thank you for the feedback, Jarlath.

I can imagine that the user might have different intentions when editing one alarm after the other, without closing the "Edit alarm" dialog:

1. He might want to edit both alarms efficiently
2. He might have clicked on Alarm #1 by mistake, when he actually meant to click on Alarm #2

I guess case (2) is less likely to occur, but it might be misleading if Alarm #1 is enabled in this case.

In revision 220, an alarm is now enabled when closing its Edit alarm dialog.

  affects ubuntu/precise/alarm-clock-applet
  status confirmed
  subscribe ubuntu-sru

--
Kind regards,
Loong Jin

This bug is missing information detailed in https://wiki.ubuntu.com/StableReleaseUpdates#Procedure for it to comply with Stable Release Updates process. Please add a test case for recreating and the regression potential. Once this information is added to all the bugs addressed by the package in -proposed we will approve the upload. Thanks!

I've rejected this from the precise-proposed queue; changing the debhelper compat level is not a minimal change, and is not appropriate for an SRU.

The rest of the changes look good (although this one is borderline), however. Feel free to re-upload a package without the debhelper change.

The Precise Pangolin has reached end of life, so this bug will not be fixed for that release