Rethinking the KOrganizer reminder daemon

[Allen Winter]

On Thursday, August 19, 2021 11:42:22 AM EDT Volker Krause wrote:
> 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.
> 
I hope you don't think I'm blocking, cause I'm not.
I am somewhat concerned that some "enterprise-y and business-y" features
might get lost with simple notifications.  I don't think losing the procedure&&email
notifications is a huge deal.  maybe we can figure out a work-around for
isMyCalendarIncidence() some day.  at least for Kolab calendars.  if there is demand.

maybe what's really needed is a separate Reminders application.
I will say that simple notifications (like the Mac has) are not nearly business-y enough for me.


> 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
> 
> 


-- 
Allen Winter | allen.winter at kdab.com | Senior Software Engineer & Teamlead
KDAB (USA) LLC, a KDAB Group company
Tel. USA +1-866-777-KDAB(5322) ext3
KDAB - The Qt, C++ and OpenGL Experts
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 5272 bytes
Desc: not available
URL: <http://mail.kde.org/pipermail/kde-pim/attachments/20210819/3d238955/attachment-0001.bin>