<div><span class="gmail_quote">On 10/9/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>> On 10/8/07, Nhuh Put <<a href="mailto:nhuh.put@web.de">nhuh.put@web.de</a>> wrote:<br>> > Please don't commit it. The QDir::(to/from)nativeSeparator stuff will
<br>> break on Windows<br>> > (for example URLs don't use \, also on Windows).<br>><br>> I don't understand what you mean by this, that is only used with the path<br>> entries (readPath/writePath/readPathLi
st/writePathList),<br>> but why else would you want to store \ in an entry unless it is a path on<br>> Windows? In that case using readPath/writePath should work.<br>> readEntry/writeEntry with QUrl/KUrl don't use the Path functions so they
<br>> shouldn't be affected by this change. Trying to fix generic strings with \<br>> at the end I don't think can be fixed without converting the \ to something<br>> else, because KConfigGroup will always think it is an escaped separator.
<br>><br><br>The problem aren't path's on windows. They \ are converted to / inside KDE anyway,<br>and also stored in this form. By calling toNativeSeparators in the read methods,<br>you will break stuff all over the place.
<br>Also, sometimes there are file URLs stored using the path methods, see the logic<br>in translatePath().</blockquote><div><br class="webkit-block-placeholder"></div><div>yes, I know. Ok, get rid of toNativeSeparators, just use fromNativeSeparators to make sure they are converted before being stored. 
</div><br><blockquote class="gmail_quote" style="margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex">I'm working on doing the list parsing and writing in the backend, with some luck<br>it will be ready by tomorrow.
</blockquote><div><br class="webkit-block-placeholder"></div><div>how are you doing that if KEntry only stores a QByteArray? </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,<br>> which is wrong imho.<br>><br>> that's the point, the only times you should ever have a null entry is when<br>> it is first constructed before it has been set to something, and when it is
<br>> deleted. Why else would you want to store a null QByteArray? If you look at<br>> the patch the reason writing an empty list failed was because I forgot to<br>> initialize a variable to "" and was passing a null QByteArray instead of an
<br>> empty QByteArray. IMHO null and empty QByteArray's should _not_ be treated<br>> the same.<br><br>You fixed the problem inside KConfigGroup, because you now how it works.<br>But the same pattern is often used in applications and the application developers
</blockquote><div><br class="webkit-block-placeholder"></div><div>where? </div><br><blockquote class="gmail_quote" style="margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex">will probably not now how it works and wonder why writing an empty (or null)
<br>QByteArray deletes the entry. This can lead to some nasty suprises.</blockquote><div><br class="webkit-block-placeholder"></div><div>That's what API docs are for. Writing a null QByteArray will delete the entry, writing an empty QByteArray will store an empty entry in the config file. null and empty are _not_ treated the same.
</div></div>