[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-core-devel
Subject:    Re: QDom as an alternative to KConfig?
From:       David Faure <david () mandrakesoft ! com>
Date:       2001-03-31 23:27:23
[Download RAW message or body]

On Sunday 01 April 2001 00:12, Kurt Granroth wrote:
> Harri Porten wrote:
> > This thought comes up from time to time. Since they day KConfig was
> > split into backend and frontend it might also be possible to put an XML
> > backend into KConfig. Without any API extensions you won't get your
> > wanted benefits like nesting from this, of course.
>  
> Yeah, if I remember correctly, some months ago, I was on IRC and
> somebody mentioned that they had a KConfig backend that used XML.  The
> reaction on IRC was that that was a waste of time and he dropped the
> idea.  I don't remember any more than that :-)

I'll refresh your mind, then :) The "somebody" who started (if even started,
certainly not fully done as you seem to imply :), was Charles,
and the "somebody" who thought it wasn't such a good idea was me
(and maybe Simon too). The point that hasn't been mentionned here
is that the strength of the current KConfig format is that it's easy to
understand for an intermediate user that looks into a file, and easy
to read. It happens quite often that to fix a problem we tell users:
remove this key from that file, or add that key there. Of course the real
solution is to have a GUI around everything, but in some cases it's handy
to be able to go into a file and fix it.

With XML it makes it quite more complex. It's still "human readable" in
theory since it's text-based, but it's much harder to grasp for someone
who doesn't know HTML or XML.
I think XML is fine for some cases where the data is structured in a 
complex way (bookmarks is a good example), but KConfig should still
be preferred for applications configuration as much as possible, IMHO.
The question is if merging with global data is needed, since there is no
solution with XML (QDom) currently.... I guess this is where something
could be done - but not necessarily with KConfig's API.

The problem with old uncleaned key could be solved by implementing
a limited removeKey/removeGroup in KConfig that only works if the
key or group is in the local file and not in any "more global" file,
and documented to exist only for cleanup purposes, and doesn't
guarantee to suceed.
This way apps could _try to_ remove the old settings when they convert them
to new ones, and that would succeed if the settings were only in a local file.
If a global file had them, then nothing happens, they remain there,
but the app doesn't use them anymore.

Just my 2 cents.

-- 
David FAURE, david@mandrakesoft.com, faure@kde.org
http://perso.mandrakesoft.com/~david/, http://www.konqueror.org/
KDE, Making The Future of Computing Available Today

[prev in list] [next in list] [prev in thread] [next in thread]