Rethinking the KOrganizer reminder daemon

[Volker Krause]

On Donnerstag, 19. August 2021 17:55:41 CEST Allen Winter wrote:
> 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.

Sure, don't worry, I fully expected some of the proposed changes to be 
controversial, but I do need feedback on what people want instead :)

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

Interesting, as I am almost exclusively using reminders in a work context as 
well, and that's exactly where I would want to get rid of the obtrusive 
dialog.

 So if we assume the alarm types aren't a big deal as you said, which of the 
other features would you miss? The detailed event display? Fine-grained 
control over dismissing/suspending a set of reminders? Or things getting lost 
in general notification noise? Maybe we can find solutions for those.

Thanks,
Volker

> > 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/1d615213/attachment.sig>