list separator in config entries

Andreas Hartmetz ahartmetz at gmail.com
Mon Oct 8 09:58:28 BST 2007


2007/10/8, Nhuh Put <nhuh.put at web.de>:
> Hello
> 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.
>
Note to the viewers who have just tuned in: This is the actual snag
that kind of breaks the current design.

> 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,
>
yes, see below

>  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.
>
Not necessarily, see below.

> 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.
>
Well, supporting different (user specified, even!) list separators has
always looked like a bad idea to me so... I say we should use ";". We
can provide a standard config file upgrade script to handle the
transition.
Note also that backends with native list support don't even *need* a
list separator - the list separator is purely an implementation
detail. It should have never been configurable in the first place.

> Supporting different separators would again be hard for backends with native
> list support.
>
Why not pass lists to the backends *as lists* [either QVariantList or
a list of not-yet-escaped strings] instead of as one string?
Concatenating several strings into one and then taking that apart
again is not exactly elegant or efficient.

> 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.
>
Well, my suggestion is to, for now, implement any hack to fix the
regression - even if that means we need to escape strings three times
before writing them out.
It's not like we have a huge installed base of KDE 4 config files so
we have some wiggle room.
HOWEVER, what should probably happen right away is to remove the
configurable list separators to be done with any BIC and, where the
default argument is not used, SIC changes. That sucks big time.
/me volunteers for the porting effort. Note: That would be about two
orders of magnitude less work to handle than what we just had because
reading and writing lists doesn't happen that often.

This is all pretty controversial, so please try so stay calm mmmkay?




More information about the kde-core-devel mailing list