<br><br><div><span class="gmail_quote">On 10/8/07, <b class="gmail_sendername">Thomas Braxton</b> <<a href="mailto:kde.braxton@gmail.com">kde.braxton@gmail.com</a>> wrote:</span><blockquote class="gmail_quote" style="margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex">
<br><br><div><div><span class="e" id="q_1157fbbf9a92bfa6_1"><span class="gmail_quote">On 10/8/07, <b class="gmail_sendername">Oswald Buddenhagen</b> <<a href="mailto:ossi@kde.org" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">
ossi@kde.org</a>> wrote:</span><blockquote class="gmail_quote" style="margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex">
On Mon, Oct 08, 2007 at 01:22:02PM +0200, Andreas Hartmetz wrote:<br>> 2007/10/8, Oswald Buddenhagen <<a href="mailto:ossi@kde.org" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">ossi@kde.org
</a>>:<br>> > the question is at which point lists are serialized and therefore
<br>> > through how many escaping passes they go.<br>> ><br>> Ahem yes, I missed that.<br>> You are arguing for another refactoring of KConfig here which I assume<br>> was not your intention.<br>>
<br>
whoops. ;)<br><br>> I agree that we need to fix things right,<br>><br>exactly.<br>if another refactoring is the price to pay, we need to bite the bullet.<br>note that this is only internal stuff, so it doesn't necessarily mean a
<br>further delay.<br><br>> For the record: The refactoring would consist of moving list handling<br>> into the backend(s)<br>><br>yes.<br>given that the windows registry can handle numerical values and blobs,<br>

too, all of the type handling should move to the backends - the api<br>would only know qvariant, which would allow arbitrarily complex nesting<br>and leave complete freedom to the backend.<br>to support backends that don't provide arbitrary binary storage (in
<br>particular, text-oriented backends like ini), a serialization<br>class/namespace would be provided to share code.<br>serializers for gui classes need to be somehow external ... hmmm,<br>actually, this is a generic problem if custom data structures should be
<br>supported.<br><br>> > assuming that the spec is implemented only by people who know<br>> > anything about working escaping is pretty naive.<br>> ><br>> Programmers OTOH should know what they are doing.
<br>><br>the key is "should". particularly in the lesser known almost-one-man<br>projects the know-how is often missing. it's incredible how much crap is<br>out there. so it is crucial not to leave *anything* to interpretation in
<br>a spec.</blockquote><div><br> </div></span></div><div>couldn't KConfigGroup just escape the escape chars, and if you want to change KEntryMap, I don't really see a problem, but can't that wait until after 
4.0? It's not like we have any other backends right now. </div></div></blockquote><div><br class="webkit-block-placeholder"></div><div>I finally got a clean checkout to compile, and it looks like the fixes that were made fixed the symptoms instead of the problems, try this patch and see if it fixes all the problems, if it does I can commit it, I need to know within the next couple of hours, after that I'm off to work.
</div><div>Oh and what were those tests added to kconfigtest.cpp supposed to test? Because they failed here on a clean checkout. I don't think they are right, but I'm not sure what they are supposed to be testing, so I don't know if I should fix the tests or fix KConfigGroup to pass the tests.
</div><div><br class="webkit-block-placeholder"></div><div>Thomas</div><div><br class="webkit-block-placeholder"></div><br> </div>