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

List:       kde-frameworks-devel
Subject:    Re: New framework: KCalCore
From:       Volker Krause <vkrause () kde ! org>
Date:       2019-04-11 16:08:48
Message-ID: 31105932.mU4DJimp57 () vkpc5
[Download RAW message or body]


On Monday, 8 April 2019 02:44:46 CEST Alexander Potashev wrote:
> вс, 7 апр. 2019 г. в 17:24, Alexander Potashev <aspotashev@gmail.com>:
> > вс, 7 апр. 2019 г. в 15:45, Volker Krause <vkrause@kde.org>:
> > > 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" (application/pgp-signature)]

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