Rethinking the KOrganizer reminder daemon

[Volker Krause]

On Donnerstag, 19. August 2021 01:48:59 CEST Carl Schwan wrote:
> Le samedi 7 août 2021 à 12:47 PM, Volker Krause <vkrause at kde.org> a écrit :
> > Hi,
> 
> Hi :)
> 
> Apologies for the delay. Actually, I already sent a reply a few days ago but
> it seems my SMTP config in KMail broke and I didn't get sent as well as a
> few other emails :(.
> > how we handle event reminders came up in a recent Plasma Mobile
> > calendaring
> > discussion, I've tried to put that into a concrete proposal here.
> > For KOrganizer event reminders are handled by korgac [1], a 20+ year old
> > piece of code. While that works reasonably well from a technical POV,
> > there's a number of issues worth addressing IMHO:
> > 
> > (A) Security/privacy: korgac still has support for iCal alarm types
> > "email"
> > and "procedure", something that shouldn't exist in a world of shared
> > calendars and iCal invites.
> > 
> > (B) UX: the main UI is a big dialog popping up in the middle of your
> > screen. We nowadays have a much more powerful desktop-wide notification
> > system supporting grouping, interaction, priorities and various
> > inhibition mechanisms, which would be better suited for this.
> > 
> > (C) Duplication of the reminder logic with other calendaring apps, see
> > e.g.
> > Calindori's implementation [2].
> > 
> > As a way forward, we could:
> > 
> > (1) Drop support for iCal alarm types due to their danger, and handle all
> > alarms as regular notifications. For the rare cases where people actually
> > rely on that functionality KAlarm provides that for local (safe) sources.
> > 
> > (2) Use KNotification as the main and only UI for reminders. This means in
> > order to see event details beyond the title you would need to click on the
> > notification to open the calendar app. This also means the suspend option
> > would only be able to have an automatic default time (this is the only
> > functionality change I'm not entirely sure about, but it matches what is
> > usually offered on phones for example). Dismissing/suspending individual
> > or
> > all reminders remains possible thanks to notification grouping.
> > 
> > (3) Base this on Nico's KCalCore plugin work once that becomes available
> > for Akonadi as well.
> > 
> > (4) Standardize the D-Bus interface towards the calendaring app between
> > KOrganizer, Calindori and Kalendar.
> 
> I would propose for that to use the existing Korganizer
> org.kde.Korganizer.Calendar.xml interface (and rename it to just
> org.kde.Calendar.xml).

Right, that's certainly a good starting point.

> > (5) Find a way to define a "default calendaring app" (like it's done for
> > web browsers), so that the reminder daemon doesn't need to hardcode which
> > calendaring app to launch. With (3) - (5) we should have all the pieces
> > to move towards a single unified reminder daemon that works with all our
> > calendaring apps, and works well both on desktop and mobile.
> 
> I saw something made by David Faure in the freedesktop mailing list around
> this idea of being able to define default applications for use cases. Would
> probably be a good idea to use this once ready:
> https://lists.freedesktop.org/archives/xdg/2021-May/014496.html

Interesting, that looks like what we need here indeed!

> > (4) and (5) could also be beneficial for the Plasma calendar integration.
> 
> Yeah also we should port the plasma calendar integration to the new Calendar
> plugin system.
> 
> > Thoughts?
> 
> The plan sounds good. My only worry is how to synchronize event deletion
> when for example the entire Akonadi database is deleted. I guess we should
> in a way verify that the event still exists before triggering a
> notification.

Right, that shouldn't be a new problem though, calendar changes (including 
deletions) should be signaled and that needs to be handled correctly of 
course.

Seeing the approval-reluctance at the first small step in this direction on 
https://invent.kde.org/pim/korganizer/-/merge_requests/43 I'm wondering if 
this approach has enough support though.

A possible alternative could be to keep korgac around largely untouched, 
implement the proposed changes in a copy, and offer a choice between the two 
in KOrganizer. Certainly not my preferred outcome, but still better than e.g. 
the mentioned per-calendar configuration for the problematic alarm types.

Regards,
Volker

> > [1] https://invent.kde.org/pim/korganizer/-/tree/master/korgac
> > 
> > [2] https://invent.kde.org/plasma-mobile/calindori/-/tree/master/calindac

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 195 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kde-pim/attachments/20210819/965d604f/attachment.sig>