list separator in config entries

[Thomas Braxton]

On 10/8/07, Oswald Buddenhagen <ossi at kde.org> wrote:
>
> On Mon, Oct 08, 2007 at 01:22:02PM +0200, Andreas Hartmetz wrote:
> > 2007/10/8, Oswald Buddenhagen <ossi at kde.org>:
> > > the question is at which point lists are serialized and therefore
> > > through how many escaping passes they go.
> > >
> > Ahem yes, I missed that.
> > You are arguing for another refactoring of KConfig here which I assume
> > was not your intention.
> >
> whoops. ;)
>
> > I agree that we need to fix things right,
> >
> exactly.
> if another refactoring is the price to pay, we need to bite the bullet.
> note that this is only internal stuff, so it doesn't necessarily mean a
> further delay.
>
> > For the record: The refactoring would consist of moving list handling
> > into the backend(s)
> >
> yes.
> given that the windows registry can handle numerical values and blobs,
> too, all of the type handling should move to the backends - the api
> would only know qvariant, which would allow arbitrarily complex nesting
> and leave complete freedom to the backend.
> to support backends that don't provide arbitrary binary storage (in
> particular, text-oriented backends like ini), a serialization
> class/namespace would be provided to share code.
> serializers for gui classes need to be somehow external ... hmmm,
> actually, this is a generic problem if custom data structures should be
> supported.
>
> > > assuming that the spec is implemented only by people who know
> > > anything about working escaping is pretty naive.
> > >
> > Programmers OTOH should know what they are doing.
> >
> the key is "should". particularly in the lesser known almost-one-man
> projects the know-how is often missing. it's incredible how much crap is
> out there. so it is crucial not to leave *anything* to interpretation in
> a spec.


couldn't KConfigGroup just escape the escape chars, and if you want to
change KEntryMap, I don't really see a problem, but can't that wait until
after 4.0? It's not like we have any other backends right now.

Thomas
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20071008/92875c13/attachment.htm>