https://bugs.kde.org/show_bug.cgi?id=481166
--- Comment #7 from David Jarvie <djar...@kde.org> --- Many of your proposals go beyond the intended scope of KAlarm, and if implemented would expand its function from being a stand-alone personal alarm application to something more general. This would add more code complexity, and therefore more maintenance overhead, which I don't think are desirable for the application as it is designed. Specific comments are below. > (My answers rest on https://github.com/KDE/kalarm/tree/master/src I don't know the status of that repository. The correct one is at https://invent.kde.org/pim/kalarm . > The "Related To" property (see > https://www.rfc-editor.org/rfc/rfc5545#section-3.8.4.5). > > KAlarm would then generate a dependent object (child), referencing back to > the parent object in the r/o ICS of the other application. > > With any luck »kcal« already has implemented it, and might even has a > complete view of all calendars within KAlarm, so that it just works … > > In effect the child would have access to changes of the parent, especially > deletion or start/end changes (for relative alarms) and any need to write > anything back into the shared ICS would vanish … I think that for simplicity, I'd prefer to treat read-only calendars as they are currently. They lack functionality in certain respects, but I would regard this as "user beware", since they are not a common usage. > RFC 5545 not only allows but advocates that VEVENT/VTODO can each have > multiple VALARMs with absolute or relative time specifications triggering > at different points in time (and actually each VALARM can have its own > summary and description, which is useful for some use-cases (example see > below)). > > KAlarm should be capable to cope with this and the ICAL library may already > is … The ical library does cope with this. However, KAlarm always creates a separate VEVENT for each alarm, and this is a fundamental assumption in its design. It would add considerable complexity to cater for a read-write calendar containing events with multiple alarms but again because this can only happen with calendars created by other applications, which is not the usual use case, I would be against catering for multiple independent alarms in the same VEVENT. Multiple alarms in a VEVENT or VTODO could be catered for an import function instead, which would split such instances into multiple VEVENTs or VTODOs, so as to conform to what KAlarm is designed to use. If a user tried to configure KAlarm to access a calendar containing such instances, the user could be prompted to import it, with a warning that otherwise, some alarms would be ignored. > I can imagine many use-cases where KAlarm and the other application act as > peers, both writing changes back with collision avoidance done by some > outside mechanism. For KDEPIM applications, that would require reverting to using Akonadi as the backend interface. This is out of the question since the use of Akonadi in KAlarm version 2 resulted in continual difficult to fix bugs, which is why a new direct file interface was developed for KAlarm version 3. > Finally I see some asymmetric use-cases where KAlarm is ancillary as a > reminder manager for a calendaring application. > The calendaring application is the owner/manager of the events and todos – > and the place for editing them. > KAlarm allows fine-tuned managing of the reminders and has r/o access to the > calendar of the other application. > > Technically I hope "Related To" works as solution. > > From the user's point of view: > When a "Related To" alarm is edited, the GUI shows the summary and > description of the event/todo as read-only together with some hint of the > managing application (typically indicated in the ICAL file) and the > external calendar and an indication that the event itself must be managed > there, whereas KAlarm only manages the reminder. The timing, summary > (name), and description (message) of the alarm proper can still be edited > by the user as normal. This is all out of scope, as explained in my first paragraph. The rest of what you suggest is also out of scope. If users want to use KAlarm to manage their alarms in place of their calendaring applications (can't they find calendaring applications which handle alarms?), they will need to import them or set them up manually in KAlarm. -- You are receiving this mail because: You are watching all bug changes.
