[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-frameworks-devel
Subject:    Re: New framework: KCalCore
From:       Allen Winter <winter () kde ! org>
Date:       2019-04-14 14:21:47
Message-ID: 5267430.DvuYhMxLoT () zazzy
[Download RAW message or body]

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. 
> 


[prev in list] [next in list] [prev in thread] [next in thread]