[prev in list] [next in list] [prev in thread] [next in thread]
List: kde-frameworks-devel
Subject: Re: New framework: KCalCore
From: Volker Krause <vkrause () kde ! org>
Date: 2019-04-17 16:40:13
Message-ID: 2551463.eqpE3CUNdh () vkpc5
[Download RAW message or body]
On Sunday, 14 April 2019 13:31:41 CEST David Faure wrote:
> On dimanche 7 avril 2019 14:45:09 CEST Volker Krause wrote:
> > Hi,
> >
> > I'd like to propose KCalCore for review to move from KDE PIM to KF5.
> >
> > KCalCore is an implementation of the iCalendar standard based on libical,
>
> I wonder about the name, which doesn't mean much outside the circle of PIM
> people. Shouldn't this be called KCalendar ?
>
> If the "Core" simply means non-GUI, we certainly don't have that word in
> every non-GUI framework.
Renaming the namespace should be manageable, we can soften the blow for
external users with a namespace alias I guess, to at least keep SC until
everyone has adapted.
> > covering the data model, input/output and the rather complex recurrence
> > algorithms defined in that standard. It's used outside of KDE PIM as well,
> > e.g. by Zanshin or the Plasma Mobile calendar app.
>
> This makes me wonder: where does that mobile calendar app get the events
> from? Akonadi? (then it still depends on kde/pim/*, and this move in itself
> doesn't really remove the unwanted workspace->apps dependency?)
So far it looked like just a local ical file, which I guess is temporary,
while focusing on mobile UI development. Eventually I at least expect the need
for KDav there too. So just moving KCalCore isn't going to be enough
obviously, but it is a necessary first step either way.
> Zanshin does use akonadi (though one could imagine a mobile version that
> only uses KDav and KCalCore^H^H^H KCalendar).
>
> Some review:
>
> icalformat_p.h: //TODO: KDE5, move this implementation to
> icalformat_p.cpp incidencebase.h: * // TODO_KDE5: Provide a virtual
> serialize() method, as done with assign() and equals(). incidencebase.h: *
> // TODO_KDE5: Provide a virtual serialize() method, as done with assign()
> and equals(). person.h: // TODO_KDE5: FIXME: This operator does
> slicing,if the object is in fact one of the derived classes (Attendee)
Person/Attendee I'd like to ideally see split into two non-polymorphic value
types, as that would make direct QML consumption easier. That would also
address the slicing risk.
Regards,
Volker
["signature.asc" (application/pgp-signature)]
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic