Re: New framework: KCalCore
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 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 wrote: > > > > > > On Monday, 15 July 2019 18:43:42 CEST Aleix Pol wrote: > > > > > > > On Fri, Jul 12, 2019 at 9:03 PM Allen Winter > > > > > > 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 > > > > > > >
Re: New framework: KCalCore
On samedi 20 juillet 2019 17:02:40 CEST Alexander Potashev wrote: > сб, 20 июл. 2019 г. в 13:14, David Faure : > > 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. > > Hi David, > > How about KCalendarFormats? Sounds like just a repository of formats, which this isn't. > In my opinion KCalendarCore is bad because it would suggest there must > be other KCalendar[...] libraries that depend on KCalendarCore, in a > manner similar to > - QtCore <- QtGui,QtQuick and > - KIOCore <- KIOWidgets,KIOGui. The EventViews library (in kdepim) is exactly such a library. It could be called KCalendarWidgets or KCalendarViews :-) But even if it's not named like that, that doesn't make the "Core" in KCalendarCore wrong at all. (The todo view is in korganizer itself) -- David Faure, fa...@kde.org, http://www.davidfaure.fr Working on KDE Frameworks 5
Re: New framework: KCalCore
сб, 20 июл. 2019 г. в 13:14, David Faure : > 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. Hi David, How about KCalendarFormats? In my opinion KCalendarCore is bad because it would suggest there must be other KCalendar[...] libraries that depend on KCalendarCore, in a manner similar to - QtCore <- QtGui,QtQuick and - KIOCore <- KIOWidgets,KIOGui. -- Alexander Potashev
Re: New framework: KCalCore
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 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 wrote: > > > > > On Monday, 15 July 2019 18:43:42 CEST Aleix Pol wrote: > > > > > > On Fri, Jul 12, 2019 at 9:03 PM Allen Winter > > > > 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 > > > > > > >
Re: New framework: KCalCore
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 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 wrote: > > > > On Monday, 15 July 2019 18:43:42 CEST Aleix Pol wrote: > > > > > On Fri, Jul 12, 2019 at 9:03 PM Allen Winter > 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),
Re: New framework: KCalCore
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 wrote: > > > On Monday, 15 July 2019 18:43:42 CEST Aleix Pol wrote: > > > > On Fri, Jul 12, 2019 at 9:03 PM Allen Winter 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
Re: New framework: KCalCore
On Wednesday, 17 July 2019 01:51:42 CEST Aleix Pol wrote: > On Tue, Jul 16, 2019 at 6:10 PM Volker Krause wrote: > > On Monday, 15 July 2019 18:43:42 CEST Aleix Pol wrote: > > > On Fri, Jul 12, 2019 at 9:03 PM Allen Winter 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? Thanks, Volker signature.asc Description: This is a digitally signed message part.
Re: New framework: KCalCore
On Tue, Jul 16, 2019 at 6:10 PM Volker Krause wrote: > > On Monday, 15 July 2019 18:43:42 CEST Aleix Pol wrote: > > On Fri, Jul 12, 2019 at 9:03 PM Allen Winter 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
Re: New framework: KCalCore
On Monday, 15 July 2019 18:43:42 CEST Aleix Pol wrote: > On Fri, Jul 12, 2019 at 9:03 PM Allen Winter 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 signature.asc Description: This is a digitally signed message part.
Re: New framework: KCalCore
On Fri, Jul 12, 2019 at 9:03 PM Allen Winter 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
Re: New framework: KCalCore
пт, 12 июл. 2019 г. в 19:25, Volker Krause : > - Alexander P's fundamental objections to the current KCalCore API After studing kcalcore sources again and also its usages with LXR, I realize that i would be painful to remove the FileStorage functionality because it implements format detection, and it's hard to decide in what use cases we can or cannot drop format detection (vCal1 vs iCal2). For use cases where file operations have to be asynchronous, the FileStorage layer can be ignored and ICalFormat::fromRawString()/fromString()/toString() used directly instead (however I didn't try this approach yet because it's uncommon). All in all, I agree to follow the golden rule "if it works, don't touch it". -- Alexander Potashev
Re: New framework: KCalCore
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. > > > > > > Thanks, > > Volker > > > > [1] > > https://mail.kde.org/pipermail/kde-frameworks-devel/2019-April/084057.html > >
Re: New framework: KCalCore
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 :) - 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. > > > Thanks, > Volker > > [1] > https://mail.kde.org/pipermail/kde-frameworks-devel/2019-April/084057.html signature.asc Description: This is a digitally signed message part.
Re: New framework: KCalCore
On Tue, Apr 30, 2019 at 8:52 PM Allen Winter wrote: > > Clazy is complaining about missing assign operators. Do we care? > If so, I can take a look at adding them or if anyone else wants to do that. > -Allen That will be fixed in Qt. Regards, Sergio Martins
Re: New framework: KCalCore
Clazy is complaining about missing assign operators. Do we care?
If so, I can take a look at adding them or if anyone else wants to do that.
-Allen
./src/calendar.cpp
line 305: for (it = vals.constBegin(); it != vals.constEnd(); ++it) {
=> Using assign operator but class
QTypedArrayData >::const_iterator has
copy-ctor but no assign operator
./src/calfilter.cpp
line 161: for (it = attendees.begin(); it != attendees.end(); ++it) {
=> Using assign operator but class
QTypedArrayData >::const_iterator has
copy-ctor but no assign operator
./src/freebusy.cpp
line 120: for (it = eventList.constBegin(); it != eventList.constEnd();
++it) {
=> Using assign operator but class
QTypedArrayData >::const_iterator has copy-ctor
but no assign operator
line 299: for (it = periods.constBegin(); it != periods.constEnd(); ++it) {
=> Using assign operator but class
QTypedArrayData::const_iterator has copy-ctor but no assign
operator
./src/icalformat_p.cpp
line 628: for (atIt = attachments.constBegin(); atIt !=
attachments.constEnd(); ++atIt) {
=> Using assign operator but class
QTypedArrayData >::const_iterator has
copy-ctor but no assign operator
./src/icaltimezones.cpp
line 493: begin = phase.transitions.cbegin();
=> Using assign operator but class
QTypedArrayData::const_iterator has copy-ctor but no assign operator
./src/incidencebase.cpp
line 513: for (it = d->mAttendees.constBegin(); it !=
d->mAttendees.constEnd(); ++it) {
=> Using assign operator but class
QTypedArrayData >::const_iterator has
copy-ctor but no assign operator
line 530: for (itA = d->mAttendees.constBegin(); itA !=
d->mAttendees.constEnd(); ++itA) {
=> Using assign operator but class
QTypedArrayData >::const_iterator has
copy-ctor but no assign operator
line 544: for (it = d->mAttendees.constBegin(); it !=
d->mAttendees.constEnd(); ++it) {
=> Using assign operator but class
QTypedArrayData >::const_iterator has
copy-ctor but no assign operator
./src/vcalformat.cpp
line 1603: for (eIt = d->mEventsRelate.constBegin(); eIt !=
d->mEventsRelate.constEnd(); ++eIt) {
=> Using assign operator but class
QTypedArrayData >::const_iterator has copy-ctor
but no assign operator
line 1607: for (tIt = d->mTodosRelate.constBegin(); tIt !=
d->mTodosRelate.constEnd(); ++tIt) {
=> Using assign operator but class
QTypedArrayData >::const_iterator has copy-ctor
but no assign operator
Sunday, April 7, 2019 8:45:09 AM EDT 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.
>
>
> Thanks,
> Volker
>
> [1] https://mail.kde.org/pipermail/kde-frameworks-devel/2019-April/084057.html
Re: New framework: KCalCore
On Wed, Apr 17, 2019 at 6:40 PM Volker Krause wrote: > > On Sunday, 14 April 2019 13:31:41 CEST David Faure wrote: > > On dimanche 7 avril 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, > > > > I wonder about the name, which doesn't mean much outside the circle of PIM > > people. Shouldn't this be called KCalendar ? > > > > If the "Core" simply means non-GUI, we certainly don't have that word in > > every non-GUI framework. > > Renaming the namespace should be manageable, we can soften the blow for > external users with a namespace alias I guess, to at least keep SC until > everyone has adapted. > > > > 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. > > > > This makes me wonder: where does that mobile calendar app get the events > > from? Akonadi? (then it still depends on kde/pim/*, and this move in itself > > doesn't really remove the unwanted workspace->apps dependency?) > > So far it looked like just a local ical file, which I guess is temporary, > while focusing on mobile UI development. Eventually I at least expect the need > for KDav there too. So just moving KCalCore isn't going to be enough > obviously, but it is a necessary first step either way. > > > Zanshin does use akonadi (though one could imagine a mobile version that > > only uses KDav and KCalCore^H^H^H KCalendar). > > > > Some review: > > > > icalformat_p.h://TODO: KDE5, move this implementation to > > icalformat_p.cpp incidencebase.h: * // TODO_KDE5: Provide a virtual > > serialize() method, as done with assign() and equals(). incidencebase.h: * > > // TODO_KDE5: Provide a virtual serialize() method, as done with assign() > > and equals(). person.h:// TODO_KDE5: FIXME: This operator does > > slicing,if the object is in fact one of the derived classes (Attendee) > > Person/Attendee I'd like to ideally see split into two non-polymorphic value > types, as that would make direct QML consumption easier. That would also > address the slicing risk. Aliases shouldn't be strictly necessary because the framework can be called KCal and the target KF5::CalCore, much like in KConfig. We could decide to have it this way though. Aleix
Re: New framework: KCalCore
On Sunday, 14 April 2019 20:30:07 CEST Alexander Potashev wrote: > вт, 9 апр. 2019 г. в 20:10, Volker Krause : > > On Sunday, 7 April 2019 16:24:13 CEST Alexander Potashev wrote: > > > вс, 7 апр. 2019 г. в 15:45, Volker Krause : > > > > 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. > > > > > > Hi Volker, > > > > > > While porting KTimeTracker to KF5, I noticed that KCalCore lost KIO > > > support on the way from KDELibs4 to KF 5.0. > > > > > > Of course I can subclass ICalFormat, but the FileStorage<->ICalFormat > > > relation looks weird to me: ICalFormat::save() is the method that > > > actually writes file to disk, while class name "ICalFormat" suggests > > > that it should only be concerned about iCal contents, not the I/O. > > > > > > May be CalFormat should only implement marshal/unmarshal methods, then > > > actual r/w from disk can be done in FileStorage. Otherwise, for me to > > > add KIO support right now I need to subclass ICalFormat rather than > > > FileStorage which is weird. > > > > Right. IMHO the entire file handling code should probably not be in there > > in the first place. That is, the CalStorage class hierarchy and the file > > I/O methods from the CalFormat hierachy (streaming to/from QIODevice > > rather than working with full QByteArray serialization might however make > > sense there). > > > > This is also why KIO support was a very bad idea in there, the KCalCore > > API is synchronous (predating KIO), while KIO is asynchronous, and so is > > likely any other persistence backend one might want to use. > > > > Looking at lxr.kde.org I'm however reluctant to remove any of this now > > though, this is still too widely used. > > Hi Volker, > > Thanks for your thoughts! > > Since David suggested renaming KCalCore to something else, how about we > instead 1. Redesign the API (e.g. drop file handling, etc) and call it e.g. > KCal, get it into KF5, > 2. Keep releasing KCalCore as part of KDEPIM and may be port it to > KF5::KCal as backend to reduce codebase, > 3. Deprecate KCalCore and gradually port everything to the new clean > KF5::KCal? ... > 4. PROFIT: nobody's code is hurt since the legacy KCalCore API is > still available. That's essentially rejecting the move of KCalCore to KF5, which is a perfectly valid outcome of this discussion of course. If that's going to be the consensus it would be good to know that sooner rather than later though, to not waste any time on this. Regards, Volker signature.asc Description: This is a digitally signed message part.
Re: New framework: KCalCore
On Sunday, 14 April 2019 13:31:41 CEST David Faure wrote: > On dimanche 7 avril 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, > > I wonder about the name, which doesn't mean much outside the circle of PIM > people. Shouldn't this be called KCalendar ? > > If the "Core" simply means non-GUI, we certainly don't have that word in > every non-GUI framework. Renaming the namespace should be manageable, we can soften the blow for external users with a namespace alias I guess, to at least keep SC until everyone has adapted. > > 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. > > This makes me wonder: where does that mobile calendar app get the events > from? Akonadi? (then it still depends on kde/pim/*, and this move in itself > doesn't really remove the unwanted workspace->apps dependency?) So far it looked like just a local ical file, which I guess is temporary, while focusing on mobile UI development. Eventually I at least expect the need for KDav there too. So just moving KCalCore isn't going to be enough obviously, but it is a necessary first step either way. > Zanshin does use akonadi (though one could imagine a mobile version that > only uses KDav and KCalCore^H^H^H KCalendar). > > Some review: > > icalformat_p.h://TODO: KDE5, move this implementation to > icalformat_p.cpp incidencebase.h: * // TODO_KDE5: Provide a virtual > serialize() method, as done with assign() and equals(). incidencebase.h: * > // TODO_KDE5: Provide a virtual serialize() method, as done with assign() > and equals(). person.h:// TODO_KDE5: FIXME: This operator does > slicing,if the object is in fact one of the derived classes (Attendee) Person/Attendee I'd like to ideally see split into two non-polymorphic value types, as that would make direct QML consumption easier. That would also address the slicing risk. Regards, Volker signature.asc Description: This is a digitally signed message part.
Re: New framework: KCalCore
On lundi 15 avril 2019 12:40:06 CEST Daniel Vrátil wrote: > On Sunday, 14 April 2019 20:17:54 CEST David Faure wrote: > > Maybe KCal is enough? Reminds of iCal. > > Wasn't KCal the original name of the library from pre-Akonadi times? > KCalCore was a fork of KCal with the pre-Akonadi "Resources" system > removed... See? That's perfect, it comes full circle then :-) -- David Faure, fa...@kde.org, http://www.davidfaure.fr Working on KDE Frameworks 5
Re: New framework: KCalCore
On Mon, Apr 15, 2019 at 2:52 PM David Jarvie wrote: > > > > On 15 April 2019 13:25:56 BST, Allen Winter wrote: > > On Monday, April 15, 2019 6:40:06 AM EDT Daniel Vrátil wrote: > > > On Sunday, 14 April 2019 20:17:54 CEST David Faure wrote: > > > > On dimanche 14 avril 2019 19:46:02 CEST David Jarvie wrote: > > > > > On 14 April 2019 12:31:41 BST, David Faure > > wrote: > > > > > > On dimanche 7 avril 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, > > > > > > > > > > > > I wonder about the name, which doesn't mean much outside the > > circle of > > > > > > PIM people. Shouldn't this be called KCalendar ? > > > > > > > > > > > > If the "Core" simply means non-GUI, we certainly don't have > > that word > > > > > > in every non-GUI framework. > > > > > > > > > > Renaming makes sense. KCalendar suggests it could be about > > calendar > > > > > systems, > > > > Indeed. > > > > > > > > > so to avoid that confusion, perhaps call it KiCalendar? > > > > > > > > Doesn't read very well > > > > I would want to say KCalendarEvents but I guess the more correct > > generic > > > > term would be KCalendarIncidences ... not convicing either. > > > > > > > > Maybe KCal is enough? Reminds of iCal. > > > > > > Wasn't KCal the original name of the library from pre-Akonadi times? > > KCalCore > > > was a fork of KCal with the pre-Akonadi "Resources" system > > removed... > > > > > Yep. Back to the Future. Let's stay away from "KCal" and "KCalendar" > > > > commit 6b4c1896211075fcd0b88b2c617eaacd831c9f6d > > Author: Allen Winter > > Date: Sat Jul 17 17:00:14 2010 + > > > > Add the new KCalCore library. > > > > The KCalCore library deprecates and mostly replaces the KCal library. > > KCalCore is free of any relation to the old Calendar resources and > > focuses entirely on iCalendar and vCalendar storage and data > > manipulation. > > KCalCore used QSharedPointers for safe memory access, is free of i18n > > strings and contains no methods for user interaction: KCalCore is all > > about the calendar data. > > Would KCalendarSerialization be a better name? I think that sums up its > purpose. > > -- > David Jarvie > KAlarm author, KDE developer > http://www.astrojar.org.uk/kalarm KContacts is the framework dealing with vcards (which are equivalent to iCal, for contacts). It makes sense to follow the same naming. If we really don't want calendaring functions there, we could consider calling it KiCal, I don't think it's that bad either and it's definitely more self-explanatory. Or we call it KCalendar and allow having calendar building blocks in it which could make sense as well, if required. Aleix
Re: New framework: KCalCore
On 15 April 2019 13:25:56 BST, Allen Winter wrote: > On Monday, April 15, 2019 6:40:06 AM EDT Daniel Vrátil wrote: > > On Sunday, 14 April 2019 20:17:54 CEST David Faure wrote: > > > On dimanche 14 avril 2019 19:46:02 CEST David Jarvie wrote: > > > > On 14 April 2019 12:31:41 BST, David Faure > wrote: > > > > > On dimanche 7 avril 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, > > > > > > > > > > I wonder about the name, which doesn't mean much outside the > circle of > > > > > PIM people. Shouldn't this be called KCalendar ? > > > > > > > > > > If the "Core" simply means non-GUI, we certainly don't have > that word > > > > > in every non-GUI framework. > > > > > > > > Renaming makes sense. KCalendar suggests it could be about > calendar > > > > systems, > > > Indeed. > > > > > > > so to avoid that confusion, perhaps call it KiCalendar? > > > > > > Doesn't read very well > > > I would want to say KCalendarEvents but I guess the more correct > generic > > > term would be KCalendarIncidences ... not convicing either. > > > > > > Maybe KCal is enough? Reminds of iCal. > > > > Wasn't KCal the original name of the library from pre-Akonadi times? > KCalCore > > was a fork of KCal with the pre-Akonadi "Resources" system > removed... > > > Yep. Back to the Future. Let's stay away from "KCal" and "KCalendar" > > commit 6b4c1896211075fcd0b88b2c617eaacd831c9f6d > Author: Allen Winter > Date: Sat Jul 17 17:00:14 2010 + > > Add the new KCalCore library. > > The KCalCore library deprecates and mostly replaces the KCal library. > KCalCore is free of any relation to the old Calendar resources and > focuses entirely on iCalendar and vCalendar storage and data > manipulation. > KCalCore used QSharedPointers for safe memory access, is free of i18n > strings and contains no methods for user interaction: KCalCore is all > about the calendar data. Would KCalendarSerialization be a better name? I think that sums up its purpose. -- David Jarvie KAlarm author, KDE developer http://www.astrojar.org.uk/kalarm
Re: New framework: KCalCore
On Sunday, 14 April 2019 20:17:54 CEST David Faure wrote: > On dimanche 14 avril 2019 19:46:02 CEST David Jarvie wrote: > > On 14 April 2019 12:31:41 BST, David Faure wrote: > > > On dimanche 7 avril 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, > > > > > > I wonder about the name, which doesn't mean much outside the circle of > > > PIM people. Shouldn't this be called KCalendar ? > > > > > > If the "Core" simply means non-GUI, we certainly don't have that word > > > in every non-GUI framework. > > > > Renaming makes sense. KCalendar suggests it could be about calendar > > systems, > Indeed. > > > so to avoid that confusion, perhaps call it KiCalendar? > > Doesn't read very well > I would want to say KCalendarEvents but I guess the more correct generic > term would be KCalendarIncidences ... not convicing either. > > Maybe KCal is enough? Reminds of iCal. Wasn't KCal the original name of the library from pre-Akonadi times? KCalCore was a fork of KCal with the pre-Akonadi "Resources" system removed... -- Daniel Vrátil www.dvratil.cz | dvra...@kde.org IRC: dvratil on Freenode (#kde, #kontact, #akonadi, #fedora-kde) GPG Key: 0x4D69557AECB13683 Fingerprint: 0ABD FA55 A4E6 BEA9 9A83 EA97 4D69 557A ECB1 3683 signature.asc Description: This is a digitally signed message part.
Re: New framework: KCalCore
вт, 9 апр. 2019 г. в 20:10, Volker Krause : > > On Sunday, 7 April 2019 16:24:13 CEST Alexander Potashev wrote: > > вс, 7 апр. 2019 г. в 15:45, Volker Krause : > > > 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. > > > > Hi Volker, > > > > While porting KTimeTracker to KF5, I noticed that KCalCore lost KIO > > support on the way from KDELibs4 to KF 5.0. > > > > Of course I can subclass ICalFormat, but the FileStorage<->ICalFormat > > relation looks weird to me: ICalFormat::save() is the method that > > actually writes file to disk, while class name "ICalFormat" suggests > > that it should only be concerned about iCal contents, not the I/O. > > > > May be CalFormat should only implement marshal/unmarshal methods, then > > actual r/w from disk can be done in FileStorage. Otherwise, for me to > > add KIO support right now I need to subclass ICalFormat rather than > > FileStorage which is weird. > > Right. IMHO the entire file handling code should probably not be in there in > the first place. That is, the CalStorage class hierarchy and the file I/O > methods from the CalFormat hierachy (streaming to/from QIODevice rather than > working with full QByteArray serialization might however make sense there). > > This is also why KIO support was a very bad idea in there, the KCalCore API is > synchronous (predating KIO), while KIO is asynchronous, and so is likely any > other persistence backend one might want to use. > > Looking at lxr.kde.org I'm however reluctant to remove any of this now though, > this is still too widely used. Hi Volker, Thanks for your thoughts! Since David suggested renaming KCalCore to something else, how about we instead 1. Redesign the API (e.g. drop file handling, etc) and call it e.g. KCal, get it into KF5, 2. Keep releasing KCalCore as part of KDEPIM and may be port it to KF5::KCal as backend to reduce codebase, 3. Deprecate KCalCore and gradually port everything to the new clean KF5::KCal? ... 4. PROFIT: nobody's code is hurt since the legacy KCalCore API is still available. -- Alexander Potashev
Re: New framework: KCalCore
On dimanche 14 avril 2019 19:46:02 CEST David Jarvie wrote: > On 14 April 2019 12:31:41 BST, David Faure wrote: > > On dimanche 7 avril 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, > > > > I wonder about the name, which doesn't mean much outside the circle of > > PIM people. Shouldn't this be called KCalendar ? > > > > If the "Core" simply means non-GUI, we certainly don't have that word > > in every non-GUI framework. > > Renaming makes sense. KCalendar suggests it could be about calendar systems, Indeed. > so to avoid that confusion, perhaps call it KiCalendar? Doesn't read very well I would want to say KCalendarEvents but I guess the more correct generic term would be KCalendarIncidences ... not convicing either. Maybe KCal is enough? Reminds of iCal. -- David Faure, fa...@kde.org, http://www.davidfaure.fr Working on KDE Frameworks 5
Re: New framework: KCalCore
On 14 April 2019 12:31:41 BST, David Faure wrote: > On dimanche 7 avril 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, > > I wonder about the name, which doesn't mean much outside the circle of > PIM people. Shouldn't this be called KCalendar ? > > If the "Core" simply means non-GUI, we certainly don't have that word > in every non-GUI framework. Renaming makes sense. KCalendar suggests it could be about calendar systems, so to avoid that confusion, perhaps call it KiCalendar? -- David Jarvie KAlarm author, KDE developer http://www.astrojar.org.uk/kalarm
Re: New framework: KCalCore
On Sunday, April 14, 2019 7:31:41 AM EDT David Faure wrote: > On dimanche 7 avril 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, > > I wonder about the name, which doesn't mean much outside the circle of PIM > people. Shouldn't this be called KCalendar ? > > If the "Core" simply means non-GUI, we certainly don't have that word in > every non-GUI framework. > > > 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. > > This makes me wonder: where does that mobile calendar app get the events from? > Akonadi? (then it still depends on kde/pim/*, and this move in itself doesn't > really remove the unwanted workspace->apps dependency?) > > Zanshin does use akonadi (though one could imagine a mobile version that only > uses KDav and KCalCore^H^H^H KCalendar). > > > Some review: > > icalformat_p.h://TODO: KDE5, move this implementation to icalformat_p.cpp > incidencebase.h: * // TODO_KDE5: Provide a virtual serialize() method, as > done with assign() and equals(). > incidencebase.h: * // TODO_KDE5: Provide a virtual serialize() method, as > done with assign() and equals(). > person.h:// TODO_KDE5: FIXME: This operator does slicing,if the object is > in fact one of the derived classes (Attendee) > > This would be the perfect time to make these changes, if they are valid. > > Allen, the first TODO above is from you (commit efe923294b4d7). > I don't get it, this is a _p.h file (i.e. no SC/BC guarantees), why not just > outline the method if you wanted to? > I'll remove that TODO in icalformat_p.h No idea why... from 2013. > The "TODO: KDE5:" in calendar.h however looks like pie-in-the-sky wishful > thinking, but maybe the suggestion > about merging some virtual methods makes sense, I don't know. > >
Re: New framework: KCalCore
On dimanche 7 avril 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, I wonder about the name, which doesn't mean much outside the circle of PIM people. Shouldn't this be called KCalendar ? If the "Core" simply means non-GUI, we certainly don't have that word in every non-GUI framework. > 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. This makes me wonder: where does that mobile calendar app get the events from? Akonadi? (then it still depends on kde/pim/*, and this move in itself doesn't really remove the unwanted workspace->apps dependency?) Zanshin does use akonadi (though one could imagine a mobile version that only uses KDav and KCalCore^H^H^H KCalendar). Some review: icalformat_p.h://TODO: KDE5, move this implementation to icalformat_p.cpp incidencebase.h: * // TODO_KDE5: Provide a virtual serialize() method, as done with assign() and equals(). incidencebase.h: * // TODO_KDE5: Provide a virtual serialize() method, as done with assign() and equals(). person.h:// TODO_KDE5: FIXME: This operator does slicing,if the object is in fact one of the derived classes (Attendee) This would be the perfect time to make these changes, if they are valid. Allen, the first TODO above is from you (commit efe923294b4d7). I don't get it, this is a _p.h file (i.e. no SC/BC guarantees), why not just outline the method if you wanted to? The "TODO: KDE5:" in calendar.h however looks like pie-in-the-sky wishful thinking, but maybe the suggestion about merging some virtual methods makes sense, I don't know. -- David Faure, fa...@kde.org, http://www.davidfaure.fr Working on KDE Frameworks 5
Re: New framework: KCalCore
On Monday, 8 April 2019 02:44:46 CEST Alexander Potashev wrote: > вс, 7 апр. 2019 г. в 17:24, Alexander Potashev : > > вс, 7 апр. 2019 г. в 15:45, Volker Krause : > > > 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. > > > > Hi Volker, > > > > While porting KTimeTracker to KF5, I noticed that KCalCore lost KIO > > support on the way from KDELibs4 to KF 5.0. > > Another pitfall is shared pointers required everywhere. Because of > them, one can't easily subclass KCalCore classes. Sorry for the delay, finally found the time to look into this properly. > Examples: > 1. KTimeTracker has a class [1] derived from > KCalCore::MemoryCalendar. In order to pass "this" into > KCalCore::FileStorage ctor, it also stores a QWeakPointer to recover > the associated shared pointer. I would love if KCalCore::FileStorage > could accept a plain pointer to KCalCore::Calendar, there is no reason > to make it shared pointer. There is a reason this uses shared pointers everywhere: to avoid dangling references or leaked memory. Allowing to bypass that seems like a very slippery slope. In this specific case I think the pain comes from using a class inside a calendar object that seems rather meant for being used alongside one. > 2. akonadi-calendar uses the same approach [2]. Kudos to whoever > invented this clever hack I tried to find where this is actually needed, and it seems to be entirely unused. Removed in D20472. Regards, Volker signature.asc Description: This is a digitally signed message part.
Re: New framework: KCalCore
On Sunday, 7 April 2019 16:24:13 CEST Alexander Potashev wrote: > вс, 7 апр. 2019 г. в 15:45, Volker Krause : > > 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. > > Hi Volker, > > While porting KTimeTracker to KF5, I noticed that KCalCore lost KIO > support on the way from KDELibs4 to KF 5.0. > > Of course I can subclass ICalFormat, but the FileStorage<->ICalFormat > relation looks weird to me: ICalFormat::save() is the method that > actually writes file to disk, while class name "ICalFormat" suggests > that it should only be concerned about iCal contents, not the I/O. > > May be CalFormat should only implement marshal/unmarshal methods, then > actual r/w from disk can be done in FileStorage. Otherwise, for me to > add KIO support right now I need to subclass ICalFormat rather than > FileStorage which is weird. Right. IMHO the entire file handling code should probably not be in there in the first place. That is, the CalStorage class hierarchy and the file I/O methods from the CalFormat hierachy (streaming to/from QIODevice rather than working with full QByteArray serialization might however make sense there). This is also why KIO support was a very bad idea in there, the KCalCore API is synchronous (predating KIO), while KIO is asynchronous, and so is likely any other persistence backend one might want to use. Looking at lxr.kde.org I'm however reluctant to remove any of this now though, this is still too widely used. Regards, Volker signature.asc Description: This is a digitally signed message part.
Re: New framework: KCalCore
On Sunday, 7 April 2019 18:54:19 CEST Albert Astals Cid wrote: > El diumenge, 7 d’abril de 2019, a les 14:45:09 CEST, Volker Krause va escriure: > > Hi, > > > > I'd like to propose KCalCore for review to move from KDE PIM to KF5. > > Does exceptions.h need a d-pointer? Looks like it, I'll fix that. Thanks, Volker signature.asc Description: This is a digitally signed message part.
Re: New framework: KCalCore
вс, 7 апр. 2019 г. в 17:24, Alexander Potashev : > > вс, 7 апр. 2019 г. в 15:45, Volker Krause : > > 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. > > Hi Volker, > > While porting KTimeTracker to KF5, I noticed that KCalCore lost KIO > support on the way from KDELibs4 to KF 5.0. Another pitfall is shared pointers required everywhere. Because of them, one can't easily subclass KCalCore classes. Examples: 1. KTimeTracker has a class [1] derived from KCalCore::MemoryCalendar. In order to pass "this" into KCalCore::FileStorage ctor, it also stores a QWeakPointer to recover the associated shared pointer. I would love if KCalCore::FileStorage could accept a plain pointer to KCalCore::Calendar, there is no reason to make it shared pointer. 2. akonadi-calendar uses the same approach [2]. Kudos to whoever invented this clever hack https://twitter.com/elonmusk/status/1104498091305009152 [1] https://cgit.kde.org/scratch/nalvarez/ktimetracker-filtered.git/tree/src/file/filecalendar.cpp?h=develop=d12569704d7b8c399151a46c067b51f2d6fbd8d1 [2] https://api.kde.org/frameworks-api/frameworks-apidocs/kdepim/akonadi-calendar/html/classAkonadi_1_1CalendarBase.html#ae3f11b166c0b51f4f071d3a74c6b91ba -- Alexander Potashev
Re: New framework: KCalCore
El diumenge, 7 d’abril de 2019, a les 14:45:09 CEST, Volker Krause va escriure: > Hi, > > I'd like to propose KCalCore for review to move from KDE PIM to KF5. Does exceptions.h need a d-pointer? Cheers, Albert
Re: New framework: KCalCore
вс, 7 апр. 2019 г. в 15:45, Volker Krause : > 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. Hi Volker, While porting KTimeTracker to KF5, I noticed that KCalCore lost KIO support on the way from KDELibs4 to KF 5.0. Of course I can subclass ICalFormat, but the FileStorage<->ICalFormat relation looks weird to me: ICalFormat::save() is the method that actually writes file to disk, while class name "ICalFormat" suggests that it should only be concerned about iCal contents, not the I/O. May be CalFormat should only implement marshal/unmarshal methods, then actual r/w from disk can be done in FileStorage. Otherwise, for me to add KIO support right now I need to subclass ICalFormat rather than FileStorage which is weird. P.S. Sorry for the off-topic. -- Alexander Potashev
