On Sunday, April 14, 2019 7:31:41 AM EDT 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. > > > 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? > I'll remove that TODO in icalformat_p.h No idea why... from 2013.
> 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. > >
