list separator in config entries

[Andreas Pakulat]

On 08.10.07 03:41:35, Nhuh Put wrote:
> I have by now all to me known issues fixed in KConfig except one failing
> testcase about list separators. The problem occurs on writing a list like
> "foo\" "bar". This will lead to "foo\, bar" which will be interpreted as an
> escaped separator from the read functions. This did work until now, because
> the escaping was done in KConfigGroup together with the list concatenation. 
> But as the escaping now happens in the backend, this is not easily possible
> anymore. I could write a quick fix in about half an hour for the beta
> release, but this will either move back the escaping to KConfigGroup which
> makes this whole KConfig redesign partially useless or a introduce another
> bad hack like double escaping backslashes in list entries or something.
> Escaping in the KConfigGroup would make it very hard for backends with
> native list support like the Windows registry or afaik ldap.
> The main reason for this trouble is the support for different kinds of list
> separators in KConfigGroup. Those are needed because the KDE config files
> are not freedesktop .desktop compliant because freedesktop uses ';' as a
> separator and we use a ',' but we still have to read .desktop files, which
> is the only reason afaik.
> Supporting different separators would again be hard for backends with native
> list support.
> I would suggest making the KDE config files standards compliant and support
> only the semicolon as a list separator, but I don't if this is possible
> regarding schedules/existing config files/other problems I'm not aware of.

I agree here. Even if the rest of the writing-code is not moved to the
backend "now", I don't see the problem with only allowing semicolon as
separator.

The only real question is how much code will break with that, i.e. how
many users of the custom separator exist in KDE's trunk?

Regarding breaking existing config files: We don't support reading path
entries from KDE3 config files without converting them before anyway, so
I don't see a problem with breaking lists reading as well (without
converting them before the first reading). 

Andreas

-- 
You will soon forget this.