Cread/Read/Update/Delete API for alarms
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
Indicator Date and Time |
Triaged
|
Undecided
|
Charles Kerr | ||
Ubuntu Calendar App |
Invalid
|
Medium
|
Unassigned | ||
ubuntu-ui-toolkit (Ubuntu) |
Triaged
|
Medium
|
Zsombor Egri |
Bug Description
As described in bug #1361702 we currently require "magic" tags in our VTODO events in order to treat clock-app alarms differently from other todo events imported from other calendar sources. This special treatment has to exist in both indicator-datetime and ubuntu-
In the #ubuntu-app-devel discussion on Sept 24, zsombi, mihir, nik90 and I agreed that it would make more sense to decouple the alarms from EDS altogether.
Earlier this year there was an aborted attempt to get a public "clean C" API for this into platform-API. That could be revived.
However, since that time the datetime alarm service has become the de-facto location for alarms and provides a DBus API for setting alarm duration, vibrate mode, default alarm sounds, and the like. The general agreement in the #ubuntu-app-devel discussion was that this API could be extended with an alarm create/
This latter option should be picked up post-RTM so that we can remove the temporary workarounds implemented for bug #1361702.
Changed in indicator-datetime: | |
assignee: | nobody → Charles Kerr (charlesk) |
status: | New → Triaged |
Changed in ubuntu-ui-toolkit: | |
assignee: | nobody → Zsombor Egri (zsombi) |
Changed in ubuntu-calendar-app: | |
status: | New → Triaged |
importance: | Undecided → Medium |
Changed in ubuntu-calendar-app: | |
status: | Triaged → Invalid |
Changed in ubuntu-ui-toolkit (Ubuntu): | |
assignee: | nobody → Zsombor Egri (zsombi) |
importance: | Undecided → Medium |
status: | New → Triaged |
no longer affects: | ubuntu-ui-toolkit |
I agree with Charles, especially that QtOrganizer is just not made for such a functionality we are using it right now. A proper API which would interact with indicator-datetime would be cleaner and - why not - faster than the current EDS solution.