https://bugs.kde.org/show_bug.cgi?id=481166
--- Comment #5 from David Jarvie <djar...@kde.org> --- Yes, KAlarm is for both technical and non-technical users, but to serve the latter, it needs a simple interface. More advanced users can expand the range of displayed options, and use such things as command alarms. Currently, if the user configures KAlarm to access in read-write mode a calendar which has been created by another application, KAlarm will write its own custom properties into the VEVENTs and VALARMs in order, for example, to track when recurrences were last triggered by it. If alarms are subsequently created or edited, they also will contain KAlarm custom properties. If the user also accesses the calendar file from another application such as KOrganizer, the KAlarm specific data may or may not survive, so this could alter how KAlarm functions for these alarms. Having thought about what you've said, I realise that KAlarm could handle alarms within VTODOs similarly to those in VEVENTs, and update them with its own custom properties to keep track. There isn't any need to copy VTODO alarms into VEVENTs - they can just stay in the VTODOs, and KAlarm would simply ignore the todo-specific data. Consideration would need to be given to: 1) How to handle VTODOs with multiple alarms. Currently, KAlarm stores each user-configured alarm in a separate VEVENT (although it often creates multiple VALARM instances within the VEVENT to handle different aspects of what to the user is a single alarm: for example, a display alarm which also plays a sound would contain a VALARM for display and a VALARM for sound, but there are other less obvious reasons to have multiple VALARMs). This scheme would not be able to handle two completely separate alarms in a VTODO (and indeed doesn't handle two completely separate alarms in a VEVENT either). 2) When a VTODO alarm is edited in KAlarm, should it be saved as a replacement VTODO? I presume yes. 3) It isn't just snooze information which currently isn't stored for read-only calendars. Also, data on the last triggered recurrence would be needed in order for read-only alarms to operate in the same way as read-write ones. I suppose that snooze data could perhaps be stored in KAlarm's default calendar, and if when the snooze expired the original read-only alarm or calendar was no longer available, the snooze would be ignored and the snooze data deleted. I'm less sure about keeping recurrence trigger data in the default calendar, since that is much longer lasting, but in principle it could also be done (as long as it is deleted if the read-only alarm or calendar becomes unavailable). 4) I don't understand what you are proposing about D-BUS events/notifications. Do you mean events/notifications not sent to KAlarm? If so, what types? Also, if you're saying that this stuff wouldn't work on KDE, then I don't think it really belongs in a KDE application. You can see descriptions of all the KAlarm custom properties in DESIGN-kalarmcalendar.html in the top level of the KAlarm source directory. -- You are receiving this mail because: You are watching all bug changes.
