<br><br><div><span class="gmail_quote">On 10/8/07, <b class="gmail_sendername">Andreas Hartmetz</b> <<a href="mailto:ahartmetz@gmail.com">ahartmetz@gmail.com</a>> wrote:</span><blockquote class="gmail_quote" style="margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex">

2007/10/8, Thomas Braxton <<a href="mailto:kde.braxton@gmail.com">kde.braxton@gmail.com</a>>:<br>><br>><br>><br>> On 10/8/07, Thomas Braxton <<a href="mailto:kde.braxton@gmail.com">kde.braxton@gmail.com

</a>> wrote:<br>> ><br>> ><br>> ><br>> ><br>> > On 10/8/07, Oswald Buddenhagen < <a href="mailto:ossi@kde.org">ossi@kde.org</a>> wrote:<br>> > > 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">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.<br>> >

<br>> ><br>> ><br>> > couldn't KConfigGroup just escape the escape chars, and if you want to<br>> change KEntryMap, I don't really see a problem, but can't that wait until<br>> after 4.0

? It's not like we have any other backends right now.<br>><br>> I finally got a clean checkout to compile, and it looks like the fixes that<br>> 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. > 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.

> The tests were added to test what's broken now, and in this thread we are pondering how to fix it. It's not that easy so please don't just commit something. </blockquote></div>I know what was being pondered on this thread, but if I don't understand what you think is broken then I can't fix it can I?

<div><br> </div><div>Thomas</div><div><br class="webkit-block-placeholder"></div>