[prev in list] [next in list] [prev in thread] [next in thread]
List: kde-frameworks-devel
Subject: Re: New framework: KCalCore
From: Dominik Haumann <dhaumann () kde ! org>
Date: 2019-07-18 21:24:15
Message-ID: CALi_srDvEefHg=GHGPgvJzRH2Mo4dBByP__4K9NaewTF31AckQ () mail ! gmail ! com
[Download RAW message or body]
To me this sounds as if KCal is the best choice: KCal - a library with iCal
support. It's short, closest to iCal, and does not clash with calendar
systems.
Greetings
Dominik
Allen Winter <winter@kde.org> schrieb am Do., 18. Juli 2019, 18:40:
> On Thursday, July 18, 2019 12:18:36 PM EDT Volker Krause wrote:
> > On Wednesday, 17 July 2019 01:51:42 CEST Aleix Pol wrote:
> > > 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).
> >
> > It's not necessarily the one and only file format (and support for other
> file
> > formats is possible in those libraries, KCalCore e.g. can read some iCal
> > predecessor too), but both vcard and ical have effectively been the one
> > ubiquitous data model in the past two decades for this kind of data.
> That IMHO
> > justifies the very generic naming :)
> >
> > In the earlier discussion David Jarvie raised concerns about the
> KCalendar
> > name being misleading towards a calendar systems related library. Valid
> point,
> > but IMHO the topic of calendar systems is more specialized (and
> typically an
> > implementation detail of other libs), compared to the calendar conecpt
> > KCalCore is referring to, so KCalendar vs KCalendarSystems would IMHO be
> > acceptable.
> >
> > Other views/opinions on this?
> >
> There was once a KCalendarSystem class.
> We may need to resurrect it , but I forget why. Maybe for holidays.
>
> I don't think KCalendar or KCalendarSystem is good.
>
> to make an analog of KContacts you'd have to call this KIncidences.
> I don't hate that. The library is really about Incidences. A calendar
> is basically a collection of incidences,
>
>
>
>
>
>
[Attachment #3 (text/html)]
<div dir="auto">To me this sounds as if KCal is the best choice: KCal - a library \
with iCal support. It's short, closest to iCal, and does not clash with calendar \
systems.<div dir="auto"><br></div><div dir="auto">Greetings</div><div \
dir="auto">Dominik</div></div><br><div class="gmail_quote"><div dir="ltr" \
class="gmail_attr">Allen Winter <<a \
href="mailto:winter@kde.org">winter@kde.org</a>> schrieb am Do., 18. Juli 2019, \
18:40:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 \
.8ex;border-left:1px #ccc solid;padding-left:1ex">On Thursday, July 18, 2019 12:18:36 \
PM EDT Volker Krause wrote:<br> > On Wednesday, 17 July 2019 01:51:42 CEST Aleix \
Pol wrote:<br> > > On Tue, Jul 16, 2019 at 6:10 PM Volker Krause <<a \
href="mailto:vkrause@kde.org" target="_blank" \
rel="noreferrer">vkrause@kde.org</a>> wrote:<br> > > > On Monday, 15 July \
2019 18:43:42 CEST Aleix Pol wrote:<br> > > > > On Fri, Jul 12, 2019 at \
9:03 PM Allen Winter <<a href="mailto:winter@kde.org" target="_blank" \
rel="noreferrer">winter@kde.org</a>> wrote:<br> > > > > > On \
Friday, July 12, 2019 12:23:58 PM EDT Volker Krause wrote:<br> > > > > \
> > With the 19.08 release approaching (and thus the deadline for<br> > > \
> > > > incompatible<br> > > > > > > changes if we go \
ahead with this plan), I'd like to raise this again<br> > > > > > \
> for<br> > > > > > > getting to a decision :)<br>
> > > > > > <br>
> > > > > > Summary of what happened in the past weeks:<br>
> > > > > > - the Person/Attendee slicing issue was fixed by making \
both<br> > > > > > > independent<br>
> > > > > > types - several "leaf" types were turned into \
implicitly shared<br> > > > > > > value<br>
> > > > > > types rather than being used heap-allocated inside \
shared pointers<br> > > > > > > - the dependency on the Akonadi \
supertrait.h header file was removed<br> > > > > > > - the \
virtual_hook usage in the incidence de/serialization code was<br> > > > > \
> > replaced by new virtual methods<br> > > > > > > <br>
> > > > > > Unless I missed something, the remaining unaddressed \
feedback is<br> > > > > > > down<br>
> > > > > > to:<br>
> > > > > > - Rename KCalCore to something else. I'm ok with \
executing the<br> > > > > > > rename,<br>
> > > > > > but<br>
> > > > > > somebody needs to tell me the new name :)<br>
> > > > > <br>
> > > > > I don't remember the reason for changing the name.<br>
> > > > > I vote for not changing the name. KCalCore is as good as \
any, imo<br> > > > > > <br>
> > > > > > - Alexander P's fundamental objections to the \
current KCalCore API<br> > > > > > > <br>
> > > > > > How do we proceed?<br>
> > > > > > <br>
> > > > > > Thanks,<br>
> > > > > > Volker<br>
> > > > > > <br>
> > > > > > On Sunday, 7 April 2019 14:45:09 CEST Volker Krause \
wrote:<br> > > > > > > > Hi,<br>
> > > > > > > <br>
> > > > > > > I'd like to propose KCalCore for review to \
move from KDE PIM to<br> > > > > > > > KF5.<br>
> > > > > > > <br>
> > > > > > > KCalCore is an implementation of the iCalendar \
standard based on<br> > > > > > > > libical,<br>
> > > > > > > covering the data model, input/output and the \
rather complex<br> > > > > > > > recurrence<br>
> > > > > > > algorithms defined in that standard. It's used \
outside of KDE PIM<br> > > > > > > > as<br>
> > > > > > > well,<br>
> > > > > > > e.g. by Zanshin or the Plasma Mobile calendar \
app.<br> > > > > > > > <br>
> > > > > > > KCalCore depends on Qt and libical only, making it \
a Tier 1<br> > > > > > > > functional<br>
> > > > > > > framework.<br>
> > > > > > > <br>
> > > > > > > KCalCore used to be part of part of kdepimlibs in \
the KDE4 era, so<br> > > > > > > > it's well prepared for \
complying with the API and ABI guarantees.<br> > > > > > > > \
<br> > > > > > > > I'd suggest the same timeline as proposed \
for KContacts [1].<br> > > > > > > > During<br>
> > > > > > > the PIM<br>
> > > > > > > sprint we did a number of fixes and cleanups as \
part of the review<br> > > > > > > > for<br>
> > > > > > > KF5<br>
> > > > > > > that make 19.08 the earliest release after which \
we can switch as<br> > > > > > > > well, so<br>
> > > > > > > we are looking at a switch in Sep/Oct this \
year.<br> > > > > <br>
> > > > If you don't remember, just scroll up a bit. :P<br>
> > > > <br>
> > > > I went through the thread and that's what we said:<br>
> > > > - It's a framework to understand the ical format, this is not \
conveyed<br> > > > > by the current name<br>
> > > > - The Core postfix doesn't add anything and we are already \
using it<br> > > > > for differentiating different framework targets \
(e.g. KF5::ConfigCore<br> > > > > and KF5::ConfigGui)<br>
> > > <br>
> > > "Core" had exactly the same meaning here when the widget \
parts were split<br> > > > out during the Nokia times. Less relevant today \
probably.<br> > > > <br>
> > > > I see KCal, KCalendar, KiCalendar, KiCal, KCalendarEvents,<br>
> > > > KCalendarIncidences being suggested. It's not going to be me \
who<br> > > > > chooses one though.<br>
> > > <br>
> > > If those are the options I'd vote for KCal or KCalendar, KiCal is \
too<br> > > > close to KiCad IMHO, and the rest is just unnecessarily long. \
Anyway,<br> > > > let's please have a quick decision on this, it's \
going to be a large<br> > > > change, so I'd like to get this in \
ASAP.<br> > > > <br>
> > > Thanks,<br>
> > > Volker<br>
> > <br>
> > I tend to agree. If so I'd suggest KCalendar. Following KContacts<br>
> > (which should possibly be KVCards, but we assume vcards are the one<br>
> > and only format ever for contacts).<br>
> <br>
> It's not necessarily the one and only file format (and support for other \
file <br> > formats is possible in those libraries, KCalCore e.g. can read some \
iCal <br> > predecessor too), but both vcard and ical have effectively been the \
one <br> > ubiquitous data model in the past two decades for this kind of data. \
That IMHO <br> > justifies the very generic naming :)<br>
> <br>
> In the earlier discussion David Jarvie raised concerns about the KCalendar <br>
> name being misleading towards a calendar systems related library. Valid point, \
<br> > but IMHO the topic of calendar systems is more specialized (and typically \
an <br> > implementation detail of other libs), compared to the calendar conecpt \
<br> > KCalCore is referring to, so KCalendar vs KCalendarSystems would IMHO be \
<br> > acceptable.<br>
> <br>
> Other views/opinions on this?<br>
> <br>
There was once a KCalendarSystem class.<br>
We may need to resurrect it , but I forget why. Maybe for holidays.<br>
<br>
I don't think KCalendar or KCalendarSystem is good.<br>
<br>
to make an analog of KContacts you'd have to call this KIncidences.<br>
I don't hate that. The library is really about Incidences. A calendar<br>
is basically a collection of incidences,<br>
<br>
<br>
<br>
<br>
<br>
</blockquote></div>
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic