KConfig + KComponentData (Re: KInstance redesign)

[Matthias Kretz]

On Saturday 20 January 2007 22:04, Aaron J. Seigo wrote:
> On Saturday 20 January 2007 13:18, you wrote:
> > 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?)
>
> that would make sense except that right now we don't what that is; this
> redesign may fix that though =)
>
> > 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.
>
> hm.. shouldn't kconfig simply have a reference to the KCD object rather
> than won it?

If the KConfig object doesn't increase the refcount on KComponentData then 
KComponentData can go away before the KConfig object is deleted. Which is 
what I wanted to fix.

Currently you can create your own KConfig object, use KSharedConfig and some 
code uses the KConfig object from KGlobal::config() or KInstance::config().

The problematic one is the latter. After KComponentData created its KConfig 
object it could deref its own refcount so that when nobody references the 
KComponentData object anymore (except the KConfig object) the KConfig object 
gets deleted. The reason this won't work is that many programs might keep a 
pointer to this KConfig object. A dangling pointer then...

How about making all KConfig objects refcounted as well? Like KSharedConfig 
already is? That way KComponentData could wait with dying until the refcount 
of its KConfig object reaches 1.

> > Aaron would any of this change with the work in the KConfig branch?
>
> i don't see why not ... so would KConfig then provide an optional parameter
> in its ctors that would take a KComponentData letting it know whether to
> use a given KComponentData* or the mainComponent? or how will KConfig know
> which component data to use?

If nobody sees an automated way, yes.
KConfig::KConfig(..., const KComponentData &cData = KGlobal::mainComponent());

-- 
________________________________________________________
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/823ccd5e/attachment.sig>