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
Description: This is a digitally signed message part.