[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-16 23:51:42
Message-ID: CACcA1Rr8OCdaCZOLiyWzGJvrvNZNeFO0t-nn7RvuJwqy6Xk7-g () mail ! gmail ! com
[Download RAW message or body]

On Tue, Jul 16, 2019 at 6:10 PM Volker Krause <vkrause@kde.org> wrote:
>
> On Monday, 15 July 2019 18:43:42 CEST Aleix Pol wrote:
> > 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)
>
> "Core" had exactly the same meaning here when the widget parts were split out
> during the Nokia times. Less relevant today probably.
>
> > I see KCal, KCalendar, KiCalendar, KiCal, KCalendarEvents,
> > KCalendarIncidences being suggested. It's not going to be me who
> > chooses one though.
>
> If those are the options I'd vote for KCal or KCalendar, KiCal is too close to
> KiCad IMHO, and the rest is just unnecessarily long. Anyway, let's please have
> a quick decision on this, it's going to be a large change, so I'd like to get
> this in ASAP.
>
> Thanks,
> Volker

I tend to agree. If so I'd suggest KCalendar. Following KContacts
(which should possibly be KVCards, but we assume vcards are the one
and only format ever for contacts).

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