Some of the early testers are hitting a use case that we didn't account for, that of multiple alarms set for the same time.
Indicator-datetime currently tries to pull up notifications for, and play sounds for, both notifications. That's happening by accident and is clearly not the right approach.
I can think of a couple of approaches we might take:
(1) Queue the alarms such that only one triggers at a time. This has the advantage of being simple, both in concept and in code. I'm not certain this is the most user-friendly approach, as it could be frustrating have to dismiss a queue of alarms.
(2) Somehow fold multiple alarms together. This has the advantage of being friendlier to the user as only a single snooze/dismiss prompt would be given. However it opens other questions, e.g. which of the alarms' sounds should play?
Of these two I slghtly prefer (1) for its simplicity; however, neither of these options seems perfect and I'm hoping Design may have a better suggestion
A cousin of bug #1354406
Some of the early testers are hitting a use case that we didn't account for, that of multiple alarms set for the same time.
Indicator-datetime currently tries to pull up notifications for, and play sounds for, both notifications. That's happening by accident and is clearly not the right approach.
I can think of a couple of approaches we might take:
(1) Queue the alarms such that only one triggers at a time. This has the advantage of being simple, both in concept and in code. I'm not certain this is the most user-friendly approach, as it could be frustrating have to dismiss a queue of alarms.
(2) Somehow fold multiple alarms together. This has the advantage of being friendlier to the user as only a single snooze/dismiss prompt would be given. However it opens other questions, e.g. which of the alarms' sounds should play?
Of these two I slghtly prefer (1) for its simplicity; however, neither of these options seems perfect and I'm hoping Design may have a better suggestion