[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:       Harri Porten <harri () trolltech ! com>
Date:       2001-03-31 22:10:35
[Download RAW message or body]

Frerich Raabe wrote:
> 
> Hello,
> 
> I'm about to add support for filters to KNewsTicker but I noticed an annoying
> thing. KConfig's files look more and more cluttered as the various options
> are added (and therefore saved/read). This is especially true for the filter
> or news source lists, and I currently have to have a single group for each
> news source/filter (for a similiar case, have a look at KMail's config file).
> I also found all these "dead" entries annoying but using KSimpleConfig (which
> doesn't "suffer" from those) is no option.

That's one of KConfigs shortcomings indeed from day 1.

> Therefore, Malte brought up the idea to use some kind of QDom-based
> configuration mechanism. As KNewsTicker's configuration interface is 100%
> encapsulated (in kdenetwork/knewsticker/configfrontend.[h|cpp]), I thought
> about doing exactly that: XML seems fairly well suited for all kinds of
> structured data and I'd take advantage of that for the list of news sources
> and filters.

XML, yes, but I'm not sure about the DOM interface. After all you don't
want to always iterate through to all the nodes to get your data. An
XPath interface might be the way to go. Never looked into it any closer.
 
> One disadvantage would be that I wouldn't get merging of global / local
> configuration but KNewsTicker doesn't need it anyway AFAICS as it solely
> relies on the local config.

Those tree can also be merged. The shortcoming I would predict is
*speed*. Parsing the current config files already takes quite a while
and a verbose format like XML won't make this better.
 
> So, has anybody ever experimented with this or comments/suggestions which
> might help me decide what to do next? I'd like to hear other's opinions about
> this.

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.

Still, since you are interested in having an extended config mechanism
it might be worthwhile to make it accessible to others, too. Letting the
idea mature in KNewsTicker first would be an acceptable approach.

Harri.

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