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. > 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?) 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) This would be the perfect time to make these changes, if they are valid. Allen, the first TODO above is from you (commit efe923294b4d7). I don't get it, this is a _p.h file (i.e. no SC/BC guarantees), why not just outline the method if you wanted to? The "TODO: KDE5:" in calendar.h however looks like pie-in-the-sky wishful thinking, but maybe the suggestion about merging some virtual methods makes sense, I don't know. -- David Faure, fa...@kde.org, http://www.davidfaure.fr Working on KDE Frameworks 5
