https://bugs.kde.org/show_bug.cgi?id=481166
--- Comment #4 from Flossy Cat <flossy-...@online.de> --- (In reply to David Jarvie from comment #3) > As stated in its handbook, KAlarm is designed as a personal message, email > and command scheduler. It is not designed for group use. I do not intend group use – only personal reminders. The option to schedule commands is very valuable and much needed, especially as it seems to be scratched elsewhere in KDE. > It aims to present > a simple interface (unless the user chooses to expand the options displayed) > to allow ordinary (i.e. non-technical) users to schedule alarms. Which it does very well. (But the existence of a command scheduler aims at technical users, IMHO – unless we have a very different definition ;-) > Most users only use it with its default calendars, and not with any calendars > created > by other applications. But you provide both for import of ICS files as well as r/w and r/o access to other ICAL calendars. VTODOs are integral part of the RFC 5545 specification as are VEVENTS, both using the identical VALARM substructure for reminders – users are bound to expect, that reminders reminders in ICAL/RFC-5545-conformant calenders work, ie. in reminders in their todos work the same as within their events, when importing ICS files. The change is trivial and probably very small – please point me to the place and provide some guidance, and I will do this … > The fact that KOrganizer reminders have been messed > up in recent times is unfortunate, Polite understatement of the week ;-) > but I don't want KAlarm to be amended or > expanded in any way in order to be used as an adjunct to KOrganizer to > provide its reminder functionality. KAlarm as reminder system is much better than anything I've seen so far. The unique advantages, I personally see, are: * (optional) list of recent reminders triggered – very valuable when you lose track on a stressy day * lookeahead of upcoming reminders – very valuable to e.g. shift them proactively if you need some undisturbed time or to preemptively do tasks if a meeting is cancelled * color-coding of reminders * command execution reminders As such it could improve on any existing calendaring and todo application and act as central reminder application. There a two independent avenues of interfacing: 1. (essential) enable snoozing alarms triggered by read-only ICS calendars – IMHO a very small and simple change: the snoozed reminder is copied to KAlarms standard active calendar (it should be even possible to have a reference to the original). This change would easily integrate all RFC-5545-conformant ICS calendar based applications (their reminder function could be switched of by the user …) 2. (optional) listen on the D-BUS for notifier events (»org.freedesktop.notification«) – this probably is some effort, but the change is well isolated new functionality. Code for listening on the D-BUS for this events, more or less filter logic, creating reminders from templates configured for specific notification types. Besides reacting to calendar reminders this opens up many other use-cases. This would work in any desktop environment having a D-BUS and conforming to the relevant parts of the freedesktop standard (ie. most). On any desktop without facility to run commands in reaction to notifications KAlarm would be greeted by any user sophisticated enough to automate their workflows – eg. on KDE (the facility is crippled to be mostly useless in 5 and shall be dropped in 6 …) If you completely oppose these ideas, I will not bother you further in this direction. If you are interested, I will help as much as I can. > It's up to KOrganizer to sort out its own deficiencies. I would be more than happy, if KOrganizer would just stop willingly introducing new ones ;-) > For these reasons, I don't see it as important to provide KAlarm with the > ability to read VTODOs, but I wouldn't object. It would be important to > first of all decide on how reading calendars containing VTODOs should fit > into KAlarm's user interface. No change needed in the interface at all. For processing you are using »kcal«, which out of the box should – as any RFC-5545-conformant library – be fully capable to handle this correctly anyhow. > As I said previously, I would see it as being > via some sort of import function, but I don't know whether that would > satisfy your goal of users not being surprised when VTODOs are ignored if > KAlarm is told to use a calendar which it didn't create itself. Bear in mind > that if VTODOs were edited in KAlarm, or if they contained recurrences, they > would need to be rewritten as VEVENTs (and of course, functions specific to > todos would be not show in KAlarm). Please kindly point me to the code, where you do the processing of VEVENTS, and I will provide solid and concrete technical answers. -- You are receiving this mail because: You are watching all bug changes.
