list separator in config entries

[Thomas Braxton]

On 10/9/07, Nhuh Put <nhuh.put at web.de> wrote:
>
> 2007/10/8, Thomas Braxton <kde.braxton at gmail.com>:
> > On 10/8/07, Nhuh Put <nhuh.put at web.de> wrote:
> > > Please don't commit it. The QDir::(to/from)nativeSeparator stuff will
> > break on Windows
> > > (for example URLs don't use \, also on Windows).
> >
> > 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.
> >
>
> The problem aren't path's on windows. They \ are converted to / inside KDE
> anyway,
> and also stored in this form. By calling toNativeSeparators in the read
> methods,
> you will break stuff all over the place.
> Also, sometimes there are file URLs stored using the path methods, see the
> logic
> in translatePath().


yes, I know. Ok, get rid of toNativeSeparators, just use
fromNativeSeparators to make sure they are converted before being stored.

I'm working on doing the list parsing and writing in the backend, with some
> luck
> it will be ready by tomorrow.


how are you doing that if KEntry only stores a QByteArray?

> > Also, something like writeEntry("key", QByteArray()) will delete key,
> > which is wrong imho.
> >
> > 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.
>
> You fixed the problem inside KConfigGroup, because you now how it works.
> But the same pattern is often used in applications and the application
> developers


where?

will probably not now how it works and wonder why writing an empty (or null)
> QByteArray deletes the entry. This can lead to some nasty suprises.


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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20071010/46ab2181/attachment.htm>