KConfig Bug?

David Faure dfaure at klaralvdalens-datakonsult.se
Thu Jun 26 18:46:54 BST 2003

On Thursday 26 June 2003 19:24, Benjamin Meyer wrote:
> On Thursday 26 June 2003 12:31 pm, David Faure wrote:
> > On Thursday 26 June 2003 18:25, Benjamin Meyer wrote:
> > > > I am trying to restore the config to the original state (as far as the
> > > > user is concerned).
> > >
> > > I guess the real problem stems from the fact that I am unable to
> > > determine where the default value comes from when [$d] is involved.  They
> > > could come from within the application readEntry("foo", defaultValue) or
> > > from the global config.
> >
> > [$d] really means deleted - i.e. as if the entry was not there at all, in
> > the merged view (global+local).
> >
> > So obviously you get "defaultValue" from the readEntry call when you're
> > reading an entry that has [$d] in the local config file.
> > I believe this is what you want, right?
> I want to be able to undo any changes to the local configure.  I want to be
> able to delete the "deleted key" so that I can get to the original global
> default value.

I don't think there is support in KConfig for that. As I said, KConfig presents
everything as a "merged view" - this means the "global" value doesn't exist
anymore, once it's overriden locally.

> If any value (other then the value that happens to be the 
> same as the default value) be it setting it or deleting it is written to a
> key that also has a global key then the application is unable to obtain the
> global value.

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.

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

> Or to explain it with ktoolbar: The place where the default text position is
> stated is in (for example in konsole's) global config.  How do I access that
> after something has been written to the local config?
Hmm, maybe the default text position shouldn't be there, but in the
konsole code instead.

> The global config's are similar to a 
> defined default value above and beyond what is in the binary.  Only the local
> configs actually change according to the user preferences.  Deleting a key
> should delete the local users settings and not the global configs setting
> sense the only time the global config can ever come into play anyway is when
> there is no settings in the local config.  
Yes, initial value.

> Added a [$d] gives the power back 
> in the hands of the binary to specify a default value again when the global
> config has higher precedence.
But we want that to be possible too... Delete means delete.

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

> 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
Correct. Up to now we didn't need much of the "revert to the settings
of the upper priority" though.

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

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

David Faure -- faure at kde.org, dfaure at klaralvdalens-datakonsult.se
Qt/KDE/KOffice developer
Klarälvdalens Datakonsult AB, Platform-independent software solutions

More information about the kde-core-devel mailing list