[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:       Frerich Raabe <frerichraabe () gmx ! de>
Date:       2001-04-01 0:21:57
[Download RAW message or body]

On Sunday 01 April 2001 01:54, David Faure wrote:
> On Sunday 01 April 2001 00:41, Frerich Raabe wrote:
> > I think KNewsTicker's lists of news sources and filters are a similar
> > case, a list of items, each having various properties. I personally
> > prefer to store "flat" (i.e. unstructured/non-nested) config data in a
> > KConfig object for exactly the advantages you mentioned but as soon as
> > we're dealing with lists of non-primitive items (e.g. structs) QDom looks
> > cleaner and easier to me.
>
> Out of interest, what's in that struct and how are the structs organized
> one with the other ? Looking at KNewsTicker's settings, I can't see
> something very complex (but maybe it's not committed yet ?) .... :)

kdenetwork/knewsticker/configfrontend.h holds that info. :-)

> You mention below news sources and filters... Hmm. Two lists of groups
> in the main group, and then one group per news source or filter, seems to
> be a working solution. Ugly or not is a very subjective matter ;-)

Yes, I'm very well aware that it'll work. I'm just picky when it comes to 
clean design (I'm the one who even writes 'const bool blah' ;-). It's just 
that somebody mentioned there're thoughts (plans?) about this and I'm 
interested in them. :-)

> My point is that it's not an "infinitely nested" structure like a tree
> (which definitely requires xml).

Hmmm, I might require infinitely nested structures for the filters; this is 
because I do not want to be restricted to i.e. 2 filters which are 
concatenated by or/and/whatever (like in KMail) but arbitrary numbers of 
filters, so that I end up having something like this:

List of filters
|
+-> Filter 1
+-> Filter 2
+-> ..
+-> Filter n

And each filter consists of an arbitrary number of expressions which are 
associated with a boolean operator (I think and, or and xor make sense here) 
and look like this:

HIDE articles by SLASHDOT whose headlines CONTAIN foo
SHOW articles by FRESHMEAT whose headlines MATCH $bar.*

Which means that I have effectively a three-layers deep tree like:

List of filters
|
+-> Filter 1
| +-> Expression 1
| +-> Expression 2
| +-> ..
+-> ..
+-> Filter n

Right now I fail to see how I should accomplish saving such a tree using 
KConfig (as long as we have only two layers [like we have atm], everything's 
allright) without becoming hacky (i.e. calling the group for Filter 1 "Filter 
1" and the expressions for it "Filter 1 - Expression 1").

> > In case of KNewsTicker, I have to deal with both, simple (colors, font
> > etc.) and structured (news sources, filters) data and having a KConfig
> > file and a QDom-based XML file simultaneously is almost as ugly as
> > storing the structured stuff in the KConfig file IMHO.
>
> Not necessarily. Konqueror's colors & fonts are in a kconfig,
> and the bookmarks in an XML file, and that's not ugly IMHO ;-)

That's a different case AFAICS as the bookmarks are shared among at least two 
applications (namely Konqueror and the bookmark editor) so a parted 
configuration is justified somehow. :-]

- Frerich

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