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

List:       kde-frameworks-devel
Subject:    Re: New framework: KCalCore
From:       Albert Astals Cid <aacid () kde ! org>
Date:       2019-07-20 15:40:30
Message-ID: 2038617.PI1AlVL9OZ () xps
[Download RAW message or body]

El dissabte, 20 de juliol de 2019, a les 12:14:09 CEST, David Faure va escriure:
> 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.

All names are bad to some degree, let's just choose one and make sure the API \
documentation states clearly what this is for and that should be enough.

Cheers,
  Albert

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


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