list separator in config entries

[Thomas Braxton]

On 10/8/07, Andreas Hartmetz <ahartmetz at gmail.com> wrote:
>
> 2007/10/8, Thomas Braxton <kde.braxton at gmail.com>:
> >
> >
> >
> > On 10/8/07, Thomas Braxton <kde.braxton at gmail.com> wrote:
> > >
> > >
> > >
> > >
> > > 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.
> >
> > I finally got a clean checkout to compile, and it looks like the fixes
> that
> > were made fixed the symptoms instead of the problems, try this patch and
> see
> > if it fixes all the problems, if it does I can commit it, I need to know
> > within the next couple of hours, after that I'm off to work.
> > Oh and what were those tests added to kconfigtest.cpp supposed to test?
> > Because they failed here on a clean checkout. I don't think they are
> right,
> > but I'm not sure what they are supposed to be testing, so I don't know
> if I
> > should fix the tests or fix KConfigGroup to pass the tests.
> >
> The tests were added to test what's broken now, and in this thread we
> are pondering how to fix it. It's not that easy so please don't just
> commit something.
>
I know what was being pondered on this thread, but if I don't understand
what you think is broken then I can't fix it can I?

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