Bugzilla – Bug 14716
Please add labels to alarms
Last modified: 2010-02-10 13:23:00 UTC
It would be very helpful to add a label to each alarm that is set. Instead of just seeing Alarm 1, Alarm 2, etc., users could label each alarm, such as "6:30 Weekdays", "7:00 A.M.", etc. iPhone, ipod touch, and blackberry all have this functionality.
any alarm that is on, has an automatic detail like the examples you gave.
For me it would be just the descriptive names; like "work", school", "sports", etc.
(In reply to comment #1) > any alarm that is on, has an automatic detail like the examples you gave. Any alarm that is off has no detail. I have a few alarms that I need to set for special occasions, such as getting up earlier on days that I travel. The whole point of labels is that the user can enter something descriptive that helps him/her see what alarms are set, but not necessarily active, without having to go into the menus.
I have three alarms. One for myself, one for my wife and one to get me/us up on week ends. With labels like "Alarm 1" "Alarm 2" "Alarm 3" it is confusing as to which Alarm has which function. Couldn't the Alarm handle be a variable that we could give a name, up to a certain number of characters? Then my Alarms could be labeled "me" "wife" and "weekend". Makes sense I think.
The main question is whether to override the detail with the name, or use the name with day/time details. Of course, this is directed at those who decide the UI design. I have a basic patch, but won't waste my time making changes that go against the intended design. Too many patches already sitting around without feedback already.
(In reply to comment #5) > The main question is whether to override the detail with the name, or use the > name with day/time details. Of course, this is directed at those who decide > the UI design. I have a basic patch, but won't waste my time making changes > that go against the intended design. Too many patches already sitting around > without feedback already. Although your question wan't aimed at me I'll chime in anyway! I think the new name/label should be displayed alongside (but before) the existing details. This way the information that is already available isn't lost to users who like the existing format. I know this means that the line of text will be longer but the details are already long enough to cause scrolling anyway.
Created attachment 6267 [details] basic patch adds a name param to the alarm class, plus UI for editing the name in SP, SbS Web and ip3k UI's. Currently, the given name simply bypasses the "alarm #" text without interfering with the day/time/off text currently being shown. Still TBD is the updates to the screen info if the name is editted. Currently, completion of the edit and going back still shows the old name until the screen is re-entered from top level. Web UI works ok for this because the submit causes a refresh anyway.
Is it necessary to add a new name param? Can not the existing title just be used and made editable? This was how I'd intended it to be used when I designed the class, and the class even provides functionality for editing it. All that's missing is the UI, as it wasn't deemed a needed feature. I think your patch may have broken a Russian string - it now displays oddly in my browser. I'm only looking through the bugzilla patch view though, and haven't looked at the rest of the patch in any detail.
param name doesn't matter. I used a new one in order not to mess with existing stuff since intent isn't documented (I even pondered using the comment, for which the intent is also unknown). re: russian string, disregard that hunk of the patch.
Created attachment 6271 [details] remove broken unicode hunk updated with the buggered unicode removed.
I've just had a quick look at the code, and you're right, there doesn't seem to be an existing param to store the label. The decision not to do this must have taken place before I'd done that bit of coding. There is a title param, but according to its perldoc, it's to do with the playlist's title. From the perldoc for the comment param: 'Sets/returns the optional text associated with this alarm. Comments should be brief and I<may> be displayed on a player's or controller's screen when the alarm sounds.' I would say you're right not to have used this to store the label. At the moment however, I don't believe the comment is used by the core code.
Matt Weldon doesn't work for us any more.
*** Bug 9328 has been marked as a duplicate of this bug. ***