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

List:       kde-frameworks-devel
Subject:    Re: New framework: KCalCore
From:       Allen Winter <winter () kde ! org>
Date:       2019-04-30 19:51:50
Message-ID: 9521454.nUPlyArG6x () zazzy
[Download RAW message or body]

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<QSharedPointer<KCalCore::Incidence> >::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<QSharedPointer<KCalCore::Attendee> >::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<QSharedPointer<KCalCore::Event> >::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<KCalCore::Period>::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<QSharedPointer<KCalCore::Attachment> >::const_iterator has copy-ctor \
but no assign operator

./src/icaltimezones.cpp
    line 493: begin = phase.transitions.cbegin();
    => Using assign operator but class QTypedArrayData<QDateTime>::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<QSharedPointer<KCalCore::Attendee> >::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<QSharedPointer<KCalCore::Attendee> >::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<QSharedPointer<KCalCore::Attendee> >::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<QSharedPointer<KCalCore::Event> >::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<QSharedPointer<KCalCore::Todo> >::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


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