KAboutData ownership (Re: KInstance redesign)

Matthias Kretz kretz at kde.org
Wed Jan 31 11:46:22 GMT 2007

OK, so I'll change KComponentData to take ownership of the KAboutData by 
default. All applications creating the KAboutData on the stack in main have 
to be adjusted then, though. Hmm, I guess all code that didn't leak 
KAboutData objects before has to be adjusted...

Perhaps we want to also add a flag to not take ownership? Then KComponentData 
would need a way to reset its KAboutData pointer to 0 when the object is 

Regarding Adriaans case: KAboutData objects are still "yours" until you 
pass 'em to a KComponentData. So you can still use the KAboutData objects 
like before.

On Wednesday 31 January 2007 11:09, David Faure wrote:
> On Wednesday 31 January 2007, Matthias Kretz wrote:
> > What are the uses cases for KAboutData not owned by
> > KComponentData?
> None that I can think of, so I like solution too.
> > Multiple KComponentData objects using the same KAboutData?
> It's basically what happens in koffice (the app and the part have the same
> aboutdata), but this is already coded like
> KAboutData * newKWordAboutData()
> {
>     KAboutData * aboutData=new KAboutData(...);
>     [...]
>     return aboutData;
> }
> and that code is shared between the app and the part [by being inline
> since they don't link to each other, but usually apps which provide a part
> simply have a shared lib for the common code].
> So, no problem if the aboutdata is owned by the componentdata, there.

Matthias Kretz (Germany)                            <><
MatthiasKretz at gmx.net, kretz at kde.org,
Matthias.Kretz at urz.uni-heidelberg.de
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20070131/34a4d4f5/attachment.sig>

More information about the kde-core-devel mailing list