https://bugs.kde.org/show_bug.cgi?id=481166
--- Comment #6 from Flossy Cat <flossy-...@online.de> --- (In reply to David Jarvie from comment #5) > 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. A good solution. > 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. (My answers rest on https://github.com/KDE/kalarm/tree/master/src – I hope this is the correct repository (it still has Akonadi-calls in it and you mentioned the docs where outdated, because Akonadi support was dropped …)) As your custom properties have the RFC-conformant custom property prefix you at least have done anything possible to make it work – but of course you are right: alas that is no guarantee … For KOrganizer I can report: it works correctly with an ICS file both share in R/W mode. (Both detect if the other application changed content and reread the file, but of course there are no provisions for avoiding concurrent changes (which would either corrupt the file or loose changes of one application) – but careful handling by the user …)) (Therefore my question about ICAL directory calendar sources – they, for various reasons, reduce this risk significantly …) Actually, there might be a really good solution for this: 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 … > 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. We are on the same page. > 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). 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 … > 2) When a VTODO alarm is edited in KAlarm, should it be saved as a > replacement VTODO? I presume yes. Well, KAlarm has its native entries (via command line parameters, via its own GUI, via imported ICSes or perhaps in the future from D-BUS messages – see below). For these of course: yes. Then it has external entries from ICS files shared with another ICAL-aware application. 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. 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. > 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. Again "Related To" hopefully solves this for us. > 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). We have two types of recurrences: Recurrence definition of the VEVENT/VTODO itself, and recurrence definitions within a VALARM. I give a practical us-case example to make the discussion more concrete: Here, cars have to have a technical inspection every 2 years. In my calendaring this is a todo, recurring every 2 years, starting with the first of the relevant month and due with the end of this month. (I use a todo as an event would visually clutter a whole month …) A VALARM is set to remind me one month in advance before the start. If this alarm is reported by KAlarm – say on a late friday afternoon – I know that calling the garage will be in vain till Monday. So I defer the alarm accordingly – solely within KAlarm without any change in the todo (which sits protected in a r/o calendar anyhow, waiting to trigger again in 2 years). Let's say on Monday their answering machine tells me, they are on vacation till next Monday. I defer the alarm again, by 1 week and 1 day (i.e. till Tuesday), because next Monday they will be flooded by calls. Perhaps I lay down some short note in the alarm description, why I postpone till Tuesday (still leaving the actual todo unchanged, because this note only applies to the current year and my current workflow, which is managed by KAlarm). Say, on Tuesday we fix a date for the inspection: I add an event (showing up in the calendar view) at the date in my calendaring application with some appropriate reminder setting and close/deactivate the alarm within KAlarm, because it has fulfilled its job. When the reminder for the car inspection triggers, I tidy up the car for inspection, and set a deferred alarm for driving the car to the garage. Let's discuss within the workflow of this use-case. If a calendar is used in PARENT/CHILD mode I would ignore the recurrences of the event/todo – this is the sole responsibility of the parent calendaring application as it has nothing to do with reminder management and KAlarm is NOT the owner of the event, just of the reminder. I'm unsure about recurrence definitions in the VALARM stanzas – I've never used them and personally see no real use-case, because I delay my reminders according circumstances – as lined out above. But may I'm just not imaginative enough. Therefore I'd suggest to honor recurrences with VALARMs within PARENT/CHILD mode. With native KAlarm events I'd actually would see good uses for VALARM recurrences, anyhow. > 4) I don't understand what you are proposing about D-BUS > events/notifications. Do you mean events/notifications not sent to KAlarm? Yes. > If so, what types? Probably solely/mainly those addressed to »org.freedesktop.notification«. Here two sample use cases: 1. capture reminders send to the desktop notification service by calendaring applications This implements are more loose coupling than the "Related To" approach and allows interfacing with calendaring applications not using ICAL files. The user would configure KAlarm to act upon the D-BUS message (by configuring a template with an D-BUS filter expression – the template being populated by the content of the DBUS message and instantiated into an alarm). To avoid double notification the user may silence the corresponding notifier action in the desktop notifier. 2. react upon events like loosing contact to a bluetooth device and the like This specifically could – together with a command alarm – implement something like »bluelock«, i.e. screen-locking a device when separated from a bluetooth token (smart watch, headset, etc.) worn by the owner. (I know, 2.1 this is not completely secure, as the bluetooth connection could be relayed over quite a distance by a skillful opponent – nevertheless it is a useful precaution against random theft or spying … 2.2 actually that is a job for UDEV. While I dauntlessly edit UDEV rules (always with the documention in view ;-), I know many technical users (rightfully claiming this category) which wont … And UDEV works system-wide (ok, for my laptops), while KAlarm would easily allow user-login-session specific actions … If you find this interesting, I'd go into technical detail. > 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. Technically there is absolutely no obstacle. The existing functionality is just arbitrarily removed by solitary short-sighted unimaginative decision making … (see https://bugs.kde.org/show_bug.cgi?id=481068 and https://bugs.kde.org/show_bug.cgi?id=481069) -- You are receiving this mail because: You are watching all bug changes.
