<div dir="ltr"><br><br><div class="gmail_quote">2008/7/29 Aaron J. Seigo <span dir="ltr"><<a href="mailto:aseigo@kde.org">aseigo@kde.org</a>></span><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<br>
ConfigXml really ought to be in libkdeui alongside KConfigSkeleton imho. (kdeui<br>
because it uses QColor; perhaps we could manage to shove it into kdecore using<br>
QVariant cleverly? hm.)</blockquote>I there any chance of the KConfigSkeleton classes being enhanced so you don't have to pass references to the constructors (especially references to primitive types). And then you would only be able to set and get values via property() and setProperty(), but is that a big issue? Do we need to be able to directly assign to the instance variables which are referenced? Would that be BIC and therefore impossible for KDE 4.2?<br>
<br>Otherwise, you have the complicated code to work round it in ConfigXml, where the referenced values have to be put in QLists, and tidied up when the KConfigSkeleton items are deleted. I have had to do something similar for the Ruby language bindings. For the kconfigcompiler generated code it adds signals in the setter methods to indicate when a value has been changed, which would be unnecessary if the variables couldn't be accessed directly.<br>
<br>-- Richard<br></div><br></div>