<br><br><div><span class="gmail_quote">On 10/8/07, <b class="gmail_sendername">Nhuh Put</b> <<a href="mailto:nhuh.put@web.de">nhuh.put@web.de</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>> On 10/8/07, Andreas Hartmetz <<a href="mailto:ahartmetz@gmail.com">ahartmetz@gmail.com</a>> wrote:
<br>> > 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<br>> 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<br>> 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<br>> bullet.<br>> > > > > note that this is only internal stuff, so it doesn't necessarily<br>> mean a<br>
> > > > > further delay.<br>> > > > ><br>> > > > > > For the record: The refactoring would consist of moving list<br>> handling<br>> > > > > > into the backend(s)
<br>> > > > > ><br>> > > > > yes.<br>> > > > > given that the windows registry can handle numerical values and<br>> 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<br>> 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<br>> 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<br>> crap is<br>
> > > > > out there. so it is crucial not to leave *anything* to<br>> 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<br>> 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
<br>> that<br>> > > were made fixed the symptoms instead of the problems, try this patch and<br>> see<br>> > > if it fixes all the problems, if it does I can commit it, I need to know<br>> > > within the next couple of hours, after that I'm off to work.
<br>> > > Oh and what were those tests added to kconfigtest.cpp supposed to test?<br>> > > Because they failed here on a clean checkout. I don't think they are<br>> right,<br>> > > but I'm not sure what they are supposed to be testing, so I don't know
<br>> if I<br>> > > should fix the tests or fix KConfigGroup to pass the tests.<br>> > ><br>> > The tests were added to test what's broken now, and in this thread we<br>> > are pondering how to fix it. It's not that easy so please don't just
<br>> > commit something.<br>> ><br>> I know what was being pondered on this thread, but if I don't understand<br>> what you think is broken then I can't fix it can I?<br>><br><br>Please don't commit it. The QDir::(to/from)nativeSeparator stuff will break on Windows
<br>(for example URLs don't use \, also on Windows).</blockquote><div><br class="webkit-block-placeholder"></div><div>I don't understand what you mean by this, that is only used with the path entries (readPath/writePath/readPathList/writePathList),  but why else would you want to store \ in an entry unless it is a path on Windows? In that case using readPath/writePath should work. readEntry/writeEntry with QUrl/KUrl don't use the Path functions so they shouldn't be affected by this change. Trying to fix generic strings with \ at the end I don't think can be fixed without converting the \ to something else, because KConfigGroup will always think it is an escaped separator.
</div><br><blockquote class="gmail_quote" style="margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex">Also, something like writeEntry("key", QByteArray()) will delete key, which is wrong imho.
</blockquote><div><br class="webkit-block-placeholder"></div><div>that's the point, the only times you should ever have a null entry is when it is first constructed before it has been set to something, and when it is deleted. Why else would you want to store a null QByteArray? If you look at the patch the reason writing an empty list failed was because I forgot to initialize a variable to "" and was passing a null QByteArray instead of an empty QByteArray. IMHO null and empty QByteArray's should _not_ be treated the same.
</div><br><blockquote class="gmail_quote" style="margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex">The main point is to get the KDE config files in sync with the freedesktop spec and remove<br>the possibility for custom list separators as it will lead to too many problems.
</blockquote><div><br class="webkit-block-placeholder"></div><div>I don't have a problem with this, the only thing it will break are config files that stored lists/fonts/colors, but as said in another mail on this thread those can be upgraded
</div><div> </div>I tried kconfigtest again, and I'm still not sure the tests are valid, or maybe just testing something that is invalid. Since QTest stops as soon as it gets a failure, kconfigtest actually fails the first 2 tests, if you comment out the first test it will fail on the second test, then comment out the second test and the third test passes. So I'm still not sure how/if to fix this.
</div><div><br class="webkit-block-placeholder"></div><div><br class="webkit-block-placeholder"></div>