Hi everyone, I just discussed this with Volker IRL and I found a solution to address my initial concern with the name, the fact that a developer (who's new to all this) seeing "Cal" might not understand this as meaning Calendar. At the same time, KCalendar is unclear (does it display a calendar? is it about calendar systems? etc.). And we already discussed the problem with the other alternatives (a new developer wouldn't understand Incidences, iCal isn't the only format behind all this, etc.)
So I suggested KCalendarCore, and Volker agreed. Unless there are strong objections, we'll go with that. Cheers, David. On jeudi 18 juillet 2019 23:24:15 CEST Dominik Haumann wrote: > 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 <win...@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 <vkra...@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 <win...@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, -- David Faure, fa...@kde.org, http://www.davidfaure.fr Working on KDE Frameworks 5