No way to enable alarm upon creation

Bug #824337 reported by Chow Loong Jin on 2011-08-11
This bug affects 3 people
Affects Status Importance Assigned to Milestone
Alarm Clock
Fix Released
Johannes H. Jensen
alarm-clock-applet (Debian)
Fix Released
alarm-clock-applet (Ubuntu)

Bug Description

Originally from

After creating a new alarm of type 'Alarm Clock', the alarm is not enabled. For
a new user, this is not immediately clear (there is no label for the
corresponding check boxes). Thus, I have already created an alarm that should
have gone of some time ago but didn't. Also, there is no option in the creation
dialog to enable the alarm, causing an odd extra action to be needed to set an
alarm; first create, then enable.

Please consider enabling these alarms upon creation.

[Test Case]
1. Open the alarms window by clicking on the alarm-clock-applet indicator and selecting "Show alarms"
2. Click "New alarm" (leftmost icon on the toolbar) in the alarm-clock-applet window
3. Click "Close" on the "Edit alarm" window.
4. (After fix is applied) Note that the alarm is activated.

[Regression Potential]
There is a slight behavioural change as a result of the change specific to this bug report: Newly created alarms and edited alarms are now automatically enabled by default.

Chow Loong Jin (hyperair) wrote :

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.

Johannes H. Jensen (joh) on 2011-08-11
Changed in alarm-clock:
status: New → Confirmed
Changed in alarm-clock-applet (Debian):
status: Unknown → New
Changed in alarm-clock-applet (Debian):
status: New → Confirmed
Johannes H. Jensen (joh) wrote :

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

Johannes H. Jensen (joh) wrote :

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?

Changed in alarm-clock:
milestone: none → 0.3.3
Johannes H. Jensen (joh) wrote :

Removed from 0.3.3 milestone because of lack of feedback.

Changed in alarm-clock:
milestone: 0.3.3 → none
TenLeftFingers (tenleftfingers) wrote :

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.

Johannes H. Jensen (joh) wrote :

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.

Johannes H. Jensen (joh) on 2012-05-28
Changed in alarm-clock:
milestone: none → 0.3.3
assignee: nobody → Johannes H. Jensen (joh)
importance: Undecided → Medium
Johannes H. Jensen (joh) wrote :

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

Changed in alarm-clock:
status: Confirmed → Fix Committed
Johannes H. Jensen (joh) on 2012-06-03
Changed in alarm-clock:
status: Fix Committed → Fix Released
Changed in alarm-clock-applet (Ubuntu):
status: New → Fix Released
Changed in alarm-clock-applet (Ubuntu Oneiric):
status: New → Won't Fix
Changed in alarm-clock-applet (Debian):
status: Confirmed → Fix Released

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

Kind regards,
Loong Jin

Changed in alarm-clock-applet (Ubuntu Precise):
status: New → Confirmed
Clint Byrum (clint-fewbar) wrote :

This bug is missing information detailed in 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!

description: updated
description: updated
Chris Halse Rogers (raof) wrote :

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.

To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Duplicates of this bug

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.