KConfig Bug?

Benjamin Meyer ben at meyerhome.net
Thu Jun 26 15:49:57 BST 2003

Hash: SHA1

On Thursday 26 June 2003 7:24 am, Waldo Bastian wrote:
> On Thursday 26 June 2003 00:05, Benjamin Meyer wrote:
> > When I call KConfigBase::deleteEntry("foo") and entry foo exists in my
> > global config a "foo[$d]" is created in the local config and from then on
> > when I call readEntry("foo") it doesn't see the global config.
> That's correct. The entry is deleted, from an API point of view it behaves
> as if the entry has never existed. (Although you suggested in your
> cvs-commit that hasKey() still returns it, which would be a bug.)
> > Now if I
> > change my deleteEntry("foo") to deleteEntry("foo", false, true) the local
> > config foo line is removed entirely and the global config shows up by
> > default on the next readEntry.
> That might be a bug.

This is actually the effect that I want to achieve  (i.e. the oposite of: "the 
pair is not removed from the application specific config file, but to the 
global KDE config file" or when bGlobal should == false.).  But when setting 
bGlobal to true gives me that result rather then false.

The reason it seemed to work by adding the ! (I think, not 100% sure) was that 
when it would merge the config file later it would see two bGlobal vars for 
the same key and ignore the one from the real global file, then when in 
kconfigbackend.cpp line ~650 hasDefault == false and then seeing it is set to 
be deleted calls continue, thus not writing anything for that key in the 
local config. 

> > Now here is the confusing part: the
> > deleteEntry API doc states that the second bool statement:
> >
> > void KConfigBase::deleteEntry (
> > const QString &   pKey,
> > bool bNLS = false,
> > bool bGlobal = false
> > )
> >  If bGlobal is true, the pair is not removed from the application
> > specific config file, but to the global KDE config file.
> >
> > But it seems to be doing the opposite.  When false (by default) it will
> > add the [$d] thus disabling the global entry and when true it removes the
> > line entirely thus keeping the global entry.  Is this a bug?
> That depends. If a global entry is defined (in $KDEDIR/share/kdeglobals)
> then it should add a [$d]-entry to $KDEHOME/share/kdeglobals to invalidate
> that entry. If there is NO global entry defined in $KDEDIR/share/kdeglobals
> then it is sufficient to just remove the entry from
> $KDEHOME/share/kdeglobals, if there was any.

Yah I was able to figure that part out.  So there are two options.  Delete 
from the local config (remove the line) and delete from the global config  
(add a [$d])  If bGlobal is true is should do the first one, but it is doing 
the second.

- -Benjamin Meyer
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: For info see http://www.gnupg.org


More information about the kde-core-devel mailing list