KConfig Bug?

Benjamin Meyer ben at meyerhome.net
Thu Jun 26 21:42:00 BST 2003

Hash: SHA1

> If the application wants to fallback to a given default, it should use that
> default as the 2nd param of readEntry.
> The global config file is only the initial configuration (set by the
> administrator), not something you can go back to later.

Set the local key the same as global and poof you can :)  course you can't 
tell what keys have global defaults and what don't.

> > I don't really get the point of [$d].
> It allows to delete a key from the global config file even when you don't
> have write access to the global config file. In the "merged view", [$d]
> deletes the key from the global file. Then the application's default value
> (the one it passes to readEntry) will be used.

But there is no way for an application to know if there is a global key that 
needs to be deleted before its default is used.

> Maybe what you need is a revertKey() that "reverts to the global
> config value" (keeping in mind that "global" can have multiple levels with
> $KDEDIRS, this simply means "revert the user's settings").
> Implementation-wise it would delete the key from the local config file, but
> conceptually this isn't a deletion (from the "merged view"), it's more of a
> "revert".

That works solution will work for me :)

> > Highest priority: Local <- user can change, admin can
> > Middle priority: Global <- user can't change, admin can
> > Lowest priority: Binary <- user can't change, admin can't
> > When a binary running by a users calls to delete a key (which exists in
> > both global and local) and then calls (for example) readBoolConfig("foo",
> > true) kconfig shouldn't return true just because the key was deleted
> > sense the global defaults have higher priority over the binary defaults. 
> > deleteKey should only delete the local config key.
> No, deleteKey is correct. It deletes from the "merged" config file.
> What you want is another method.

Sounds good to me.  I can already think of several dozen places I need to 
change to use that once it is added.

> > When would there be a case where you would want to have [$d]?
> To really delete something (when the user doesn't want to see something
> anymore, etc.)

Why doesn't the application just set it to false, "", etc.  The global config 
are simply another default layer with no other powers the adding and deleting 
off stuff from the config level should always take place in the local.  Yes 
they should be viewed as merged, but following the priorities level.  I think 
that the deleteEntry should remove the line rather then adding the [$d], but 
will transition all my deleteEntry() to a different function if that is what 
you all decide.

- -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