On Wed, Apr 17, 2019 at 6:40 PM Volker Krause <vkra...@kde.org> wrote: > > 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.
Aliases shouldn't be strictly necessary because the framework can be called KCal and the target KF5::CalCore, much like in KConfig. We could decide to have it this way though. Aleix