KConfig + KComponentData (Re: KInstance redesign)
kretz at kde.org
Sat Jan 20 20:18:24 GMT 2007
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) <><
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
Size: 189 bytes
Desc: not available
More information about the kde-core-devel