KAboutData ownership (Re: KInstance redesign)

[Matthias Kretz]

And another follow-up:

I just realized that KComponentData does not take ownership of the KAboutData 
and now it may outlive the common KAboutData. Most programs create the 
KAboutData object on the stack in main() but KComponentData lives longer, at 
least until the private KGlobal data is deleted.

I see two solutions:
1) let KComponentData take ownership of KAboutData (but perhaps make it 
optional)
2) make KAboutData refcounted just as I did with KComponentData (and no, this 
time I won't do all the porting alone)

I prefer 1). What are the uses cases for KAboutData not owned by 
KComponentData? Multiple KComponentData objects using the same KAboutData?

-- 
________________________________________________________
Matthias Kretz (Germany)                            <><
http://Vir.homelinux.org/
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/20070130/f117652b/attachment.sig>