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

List:       kde-frameworks-devel
Subject:    Re: New framework: KCalCore
From:       Aleix Pol <aleixpol () kde ! org>
Date:       2019-07-15 16:43:42
Message-ID: CACcA1RoSBD9btNHiLZWrwLF3zgpwHsnJNq-YtOosPEfKhFiKBg () mail ! gmail ! com
[Download RAW message or body]

On Fri, Jul 12, 2019 at 9:03 PM Allen Winter <winter@kde.org> wrote:
>
> On Friday, July 12, 2019 12:23:58 PM EDT Volker Krause wrote:
> > With the 19.08 release approaching (and thus the deadline for incompatible
> > changes if we go ahead with this plan), I'd like to raise this again for
> > getting to a decision :)
> >
> > Summary of what happened in the past weeks:
> > - the Person/Attendee slicing issue was fixed by making both independent types
> > - several "leaf" types were turned into implicitly shared value types rather
> > than being used heap-allocated inside shared pointers
> > - the dependency on the Akonadi supertrait.h header file was removed
> > - the virtual_hook usage in the incidence de/serialization code was replaced
> > by new virtual methods
> >
> > Unless I missed something, the remaining unaddressed feedback is down to:
> > - Rename KCalCore to something else. I'm ok with executing the rename, but
> > somebody needs to tell me the new name :)
>
> I don't remember the reason for changing the name.
> I vote for not changing the name. KCalCore is as good as any, imo
>
> > - Alexander P's fundamental objections to the current KCalCore API
> >
> > How do we proceed?
> >
> > Thanks,
> > Volker
> >
> > On Sunday, 7 April 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,
> > > 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.
> > >
> > > KCalCore depends on Qt and libical only, making it a Tier 1 functional
> > > framework.
> > >
> > > KCalCore used to be part of part of kdepimlibs in the KDE4 era, so it's well
> > > prepared for complying with the API and ABI guarantees.
> > >
> > > I'd suggest the same timeline as proposed for KContacts [1]. During the PIM
> > > sprint we did a number of fixes and cleanups as part of the review for KF5
> > > that make 19.08 the earliest release after which we can switch as well, so
> > > we are looking at a switch in Sep/Oct this year.

If you don't remember, just scroll up a bit. :P

I went through the thread and that's what we said:
- It's a framework to understand the ical format, this is not conveyed
by the current name
- The Core postfix doesn't add anything and we are already using it
for differentiating different framework targets (e.g. KF5::ConfigCore
and KF5::ConfigGui)

I see KCal, KCalendar, KiCalendar, KiCal, KCalendarEvents,
KCalendarIncidences being suggested. It's not going to be me who
chooses one though. ;)

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