KConfig + KComponentData (Re: KInstance redesign)

[Matthias Kretz]

On Friday 19 January 2007 14:24, David Faure wrote:
> The refcounting is not only good for the staticdeleter case, but also to
> fix some memleaks that we currently have. [...]
> All fixed by refcounting instead, which makes sense given that the 
> instance^H^Hcomponent data is used (and stored) by many different classes.

Thinking out loud:
A goal is that KConfig can be used in dtors of global statics. For that to 
work KGlobal::dirs() and such must work, i.e. the main KComponentData may not 
have been destroyed yet. (BTW, KConfig uses KGlobal::dirs() a lot, shouldn't 
it use KComponentData::dirs() of the component it's coming from instead?)

Anyway, what we'd need is that every KConfig object keeps a KComponentData 
object and get's data from it instead of from KGlobal, right?

But there we'll have a circular dependency because KComponentData owns a 
KConfig object and KConfig objects should own a KComponentData object. 
Creation is ok, but destruction would never happen.

Aaron would any of this change with the work in the KConfig branch?

Any brilliant ideas how this should work?

/me goes and works a little on phonon-xine-threaded again

-- 
________________________________________________________
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/20070120/664a4ba2/attachment.sig>